The author suggests redirecting the scope of "TDD" to testing his app's public API endpoints, rather than internal functions. His logic is that public API endpoints represent the contracts for business logic with customers, and therefore are the highest level that can be accurately tested.<p>I am not convinced of this argument. Obviously, it's important to heavily test the endpoints of any API you make public. In fact, that's a situation where you want 100% coverage. However, testing the endpoints of an API does not allow you to forego testing its internals. At best, a passing suite of API endpoints should give you <i>reasonable</i> confidence that the internals are functioning properly.<p>An API is an abstraction over many moving parts. Any good API will consolidate thousands of lines of business logic into a few endpoints. There is a lot of room for error in the layer of abstraction between API and internal logic. It's entirely possible that a API endpoints could appear to be functioning properly, but actually be relying on broken internal code.<p>For example, consider a fruit basket API. You can insert fruit into the basket, and check what fruit is in the basket. A suite of tests for the API endpoints could insert fruit, and then check that it's there. In this case, the API is hiding a lot of internal logic. Storage mechanisms, data persistence, fault tolerance, and a slew of other logic decisions are completely opaque to the API consumer.<p>What if the internal code incorrectly stores the fruit in a temporary file? The API test will pass if it inserts fruit and then checks that it's there. But it is not going to check for that same fruit in an hour. What if it's gone?<p>Internal logic like data persistence is (rightfully) opaque to API consumers. That means that no testing of API endpoints can validate all internal logic. Therefore, you cannot ignore testing the internal logic in favor of only testing API endpoints.
I'm not sure why the author attempts to redefine "unit testing" at a higher level of testing. It seems pretty well-accepted that most API tests are, in fact, integration tests. There's no need to use the term "unit test" in this case.<p>Otherwise, I quite agree. I don't write unit tests. A complete set of integration tests gives me about 80% confidence in the correctness of code. Unit tests might bump that up to 90%, but you'll never get to 100% from testing alone and the substantial effort necessary to get there just isn't worth it.<p>Testing follows the classic 80/20 rule. Integration tests only take 20% of the effort required for full unit test coverage, but can give you the bulk (80%) of the benefits. For all but the most sensitive of applications, it's probably not worth it to put in the additional 80% effort for a mere 20% gain.
I think there's a lot of value in balancing this approach with smaller sized tests, especially around complex code.<p>The problem that the article doesn't address is if your test fails finding the failure point isn't as straightforward as it is with smaller units.<p>However the points made here and in the discussions linked are valid and I think this is the right approach to testing. But I think that there's still lots of value in writing and maintaining tests around smaller units of code. Balancing the two approaches brings us solid test coverage along with easy to debug test failures.
When you have a service-oriented architecture with small, atomic services ("microservices"), unit tests are indistinguishable from functional tests: each test suite covers exactly one unit, which performs exactly one function, which maps to exactly one service with exactly one API. (Handily, in such a scenario, the service-registry also doubles as your mocking framework.)<p>I think unit tests do have one important use: testing library functions, e.g. cryptographic primitives. Most people aren't writing "library code", though; they're employing it.
Erm this smacks a little of absolutism. In many cases you'll definitely want to test at a method level - if the behaviour of a single method is complex but its not part of the API, if you want to test it properly, you'll likely still have to have a similar number of unit tests (to properly pinpoint a bug), you'll just need to move them up to the API level - and furthermore, the tests you need to come up with are far more complex, as they have to anticipate the outputs of each function call as well (in order to obtain the same coverage).<p>It's correct that by reducing your number of units and making them more broad scoped, you potentially reduce the number of undetectable faults you are catching (but need not), but you also make crafting the input that detects the remaining faults much more difficult.<p>The correct approach is (it seems obvious to me) to mix the two. Don't force tests to be on a per-method basis, but also don't neglect to individually test those methods that can be better tested by individual testing. It seems like common sense - following a policy such as this so rigidly clearly leads to either wasted time and inferior APIs or missed test cases - the former I believe the OP has discovered already, the latter I'm sure they'll discover in due time.<p><a href="http://www.quickmeme.com/img/0f/0fb4fa35fad1b9ed112dc7584f47c531cf14a1c3c55d64bed93d33d5330dfcd1.jpg" rel="nofollow">http://www.quickmeme.com/img/0f/0fb4fa35fad1b9ed112dc7584f47...</a>
This sounds a lot like Mock Client Testing:
<a href="http://www.jaredrichardson.net/blog/2005/06/20/" rel="nofollow">http://www.jaredrichardson.net/blog/2005/06/20/</a><p>(I think the writeup in the Ship It! book was better than this post)