It's intent is to provide guide when times are trying, e.g. "I’d fall into despair :)"…
Bibles are collections of fun stories to read, BTW.

:)

During the creative process I frequently change the interfaces (simply because I’m a mere mortal and I occasionaly overlook some dependencies, or other issues). If I had to write test cases first and rewrite them again and again any time I change my mind about the code structure, I’d fall into despair :) It makes much more sense to write tests once the APIs settle down a bit.

Perhaps it very much depends on one’s personal coding style? Or maybe TDD works best for simple pieces of code, where you can decide upon the interface upfront?

A more concrete example would be a UI, Product, Order and Billing context. Unit tests would be:

UI - Given known response from Product context, does UI display products correctly
Product context - Given a request for products, are the correct products returned
UI - When clicking submit, does the UI send the correct request to the Order context
Order context - Given an order request, is the correct order placed event raised
Billing - Given order placed event is received, is the correct amount invoiced

e2e test would be the whole flow through these.

This is just an example of how you might choose to define your contexts/public interfaces. You could decide that the app is one context, but then you should test everything through the UI. Also, you shouldn't be constrained into thinking that the public API is what the "customer" sees. Architectural quality factors play an important part and testability is an important factor that may lead you to split contexts. A common example of this is splitting a processing pipeline into intermediary outputs. It's all a trade off.

Also, the idea of testing at the public interface is an ideal. Sometimes you might need to be pragmatic and place tests around implementation details, but you should always be aware these tests are brittle and you should be prepared to throw them away.

So we can have one unit test for the library and another unit test for the app.

End-to-end test is a test that test both the library API and the app's API in parallel.

If that's the definition of end-to-end, I don't see much point in writing e2e tests at all.

@Luis: There's in interesting paradox involved here: Unit tests work great once the project is nearing the maintenance phase. There's no much change going on, so the test are never broken by rafactoring or such. At the same time, however, the product in the maintenance phase is already pretty stable and there's not much incentive to write unit tests.

See, the thing is that you're in a situation where the API is already ossified—you can't change its API very much because you'd break existing clients. Unit tests work great in that situation.

Where they don't work so great is when you still don't have clients and you're trying to come up with a good API. You spend a lot of effort writing a bunch of unit tests… and then you realize your API, which still doesn't have any code using it, is poorly organized. Now you have to throw out all of the existing unit tests.

The unit tests were still valid because the API didn't change. Having the tests in place made me feel confident to replace the guts in a weekend. This was a huge benefit.

Please remember that your tests form a portfolio. This portfolio of test boundaries needs to balanced based on multiple factors; engineer experience & professionalism level, technology and economic impact of a defect to name a few. Also remember to rebalance as the factors change.

It just seems that people today are overemphasising unit testing and ignoring e2e tests. I felt like a reminder of importance of e2e tests would be worth it.

As for refactoring, I don't agree. You can change the internal implementation of the component, but that's not what I call refactoring. On the other hand, you can't change the component's interaface (refactoring proper) because that would break all the unit tests.

I think the most important value derived from unit tests is having a quick feedback cycle. You write code, build it, and immediately get results. If your have nothing but e2e tests, it often takes much longer to verify that the piece you are working on works correctly.

Also, most people overlook this benefit of having good unit tests - easier refactoring. If your unit tests verify the interface of your component, you can confidently refactor and move stuff around - as long as all your unit tests passed, you can be reasonably confident that you have not broken anything. Of course, e2e test will still have to be run, unit tests are not meant to replace them. They are a tool in your arsenal that helps you write better code quickly and efficiently.