3 ms·

I am not arguing against the integration test point, but I do see a value in unit tests. When I write/modify a piece of code, I of course must see so it works.

I am not arguing against the integration test point, but I do see a value in unit tests. When I write/modify a piece of code, I of course must see so it works. I run the new code, feed in some data and see the results. If I separate UI and backend/model, I can just write code that feed data to the model to see so it works (instead of doing it ad hoc, by hand). Then I save that as a unit test. It is part of the documentation too (a use case). Cheap, easy and with good value for effort. (Depending on problem domain.) Edit: I can see where the "test induced design damage" comes from, mocking is bad, but I think code also often get better when it is made testable (dep injection, think about fan out/in, etc)

morgante 12y ago
It sounds like you're writing functional or integration tests, not method-by-method unit tests. That's all easily accomplished with integration tests. Generally, any good architecture makes a separation between the UI and the backend. You should absolutely have integration tests for the backend by itself, but I don't think it is necessary to get to the level of unit tests (testing every single method used in the backend). Personally, I try to separate the backend into its own separate service. The first step is to write tests against the API for that service, and then to make those tests pass by completing the service. This has the added benefit of letting the tests serve as a spec documentation, which makes it very easy to farm out implementation to employees or contractors.
- BugBrother 12y ago
  Sorry, missed the answer. How can quick tests to see that API (and internal stuff) work not be Unit tests? :-) But sure, it is a discussion of what we should call the useful tests. I have (also) burned out on > 80% coverage for tests when the specifications aren't written in stone.

morgante 12y ago

It sounds like you're writing functional or integration tests, not method-by-method unit tests. That's all easily accomplished with integration tests. Generally, any good architecture makes a separation between the UI and the backend. You should absolutely have integration tests for the backend by itself, but I don't think it is necessary to get to the level of unit tests (testing every single method used in the backend). Personally, I try to separate the backend into its own separate service. The first step is to write tests against the API for that service, and then to make those tests pass by completing the service. This has the added benefit of letting the tests serve as a spec documentation, which makes it very easy to farm out implementation to employees or contractors.

BugBrother 12y ago
Sorry, missed the answer. How can quick tests to see that API (and internal stuff) work not be Unit tests? :-) But sure, it is a discussion of what we should call the useful tests. I have (also) burned out on > 80% coverage for tests when the specifications aren't written in stone.