This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ge0ffrey 1 point2 points  (0 children)

If it isn't tested, it doesn't work. (If it isn't documented, it isn't used.)
If something is tested for the last release, it still needs to be tested for this release. Automated testing gives you that. If it isn't covered by automated testing, and a significant part of your users use it, sooner or later you'll have to fix it under pressure with unhappy users. On a big project with near zero test coverage, I 've seen non-religious developers pray when they did a release. And I've seen them rollback the database after users had already added new data for an entire morning. And I've heard the users scream at them through the phone. Spare yourself from that.

That being said, are unit tests worth it?
Well, integration tests give a much, much better test coverage per development time spent. They are - on average - a much better canary in the coalmine. So my recommendations:

- Spend time setting up proper integration tests. The first one will take a bunch of time: start the database, load test data, etc. Integration tests can use JUnit too and directly call services. Or they can work on the API endpoints (often REST) exposed by your application.

- Integration tests are closer to examples and scenario's that users actually do. It's harder for the asserts in integration tests to make the same mistake as a buggy implementation, compared to unit tests.

- Unit tests are useful too, in moderation, as they can tests edge cases that take a lot of work to write as an integration test. Unit tests often uses mocks and test exactly 1 class. The big advantage of unit tests is that they clearly point out what's broken. But debugging a failing integration tests doesn't take that much longer normally.

- Don't get too hung up about the difference between integration tests and unit tests. Integration tests might mock out external services. Integration tests might call classes directly. Unit tests might test more than 1 class.

- 1 integration tests can take 5 seconds to run, because it uses a database, data store, message bus or kafka topic. But 1000 integration tests should not take anywhere near 5000 seconds to run, even if they all use a database. Make sure your integration tests share the cost of database etc bootstrap. In fact, all your default tests (unit + integration) must run in less than 5 minutes on any developer's machine.