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.