Jakarta EE / MicroProfile Testing and Quality over Statistics

An airhacks.fm conversation with Andrew Guibert (@andrew_guibert)
about: the Java EE Testing survey and possible room for
improvements, testing is too hard with severe consequences,
reasonable projects are interested in delivering good software,
large enterprises are more interested in statistics, testing is
about increasing developer's confidence, confidence decreases with
the length of time spent outside the project, in 1996 you would
test with a bunch of main methods, most projects are ignoring
System Tests because the statistics are not gathered, "test first"
or last does not matter, you only have to deliver the tests with
working software at the same time, running System Tests with code
coverage, fast and long running modes, Unit-, Integration-, and
System Tests are naturally ordered by their execution time, in
business projects unit test coverage can be fairly low, in business
projects arquillian comes with a little added value, in Integration
Tests it is crucial to use the same version of libraries, tests do
not accurately represent the production environment, System Tests
are reused as Stress Tests, JMH is a great library for stress
tests, at IBM there is a dedicated performance team, in projects
torture tests are a good start, toxiproxy by shopify, management
driven code metrics is a failure of management, unit tests should
be about verifying the behaviour not the implementation details,
too many unit tests increase the costs of refactoring, unit tests
are running in seconds, integration tests in a few minutes, the
performance of system tests really depends on the system,
integration tests give more confidence, than unit tests, unit tests
are great for productivity, running servers in code coverage modes
would be useful, jacoco code coverage metrics could be exposed via
JSON, Andy on twitter: @andrew_guibert and github.