Bryan, I agree with you (90%). (Yes, loved "Interstellar.") ... "you have end to end tests because your architecture is broken." – I approach testing as a "test pyramid" where integration testing is the very, very tip of the pyramid. There should only one. Or two, maybe three. Under that are smaller and smaller scope tests, working down from acceptance, to component, to unit... where you have this huge base of your pyramid built on unit tests or functional tests.
But I think we need that "one" integration test – because it's our proof. Theories need proofs. In theory, all those unit tests work and therefore all the components work and therefore the system works. My "proof" is a single top-level working end-to-end tests that shows I have a solid foundation. (And I didn't screw up somewhere). 😄
I'm one of those (of MANY!!!) who (almost entirely) DO NOT make a list of tests before starting a TDD session. And I learned this from members of the C3 project, where TDD was found/created/developed. Sure, traditional development approaches have always advocated "First, Make a Test Plan." But many of us have found that TDD works well, in practice, without much up-front thinking or planning. Most of the thinking, design, etc. happens during the Refactoring step. So it often turns out to be premature to do too much up-front.
(Extreme Programming, as a philosophy, is generally "anti-up-front" in a number of ways -- planning, scheduling, documentation, etc.)
The "zero, one, many" is where I suggest "First, ask for the song for ZERO bottles of beer on the wall.", and then "ONE bottle of beer", and then "TWO bottles of beer", etc.
Bryan, I agree with you (90%). (Yes, loved "Interstellar.") ... "you have end to end tests because your architecture is broken." – I approach testing as a "test pyramid" where integration testing is the very, very tip of the pyramid. There should only one. Or two, maybe three. Under that are smaller and smaller scope tests, working down from acceptance, to component, to unit... where you have this huge base of your pyramid built on unit tests or functional tests.
But I think we need that "one" integration test – because it's our proof. Theories need proofs. In theory, all those unit tests work and therefore all the components work and therefore the system works. My "proof" is a single top-level working end-to-end tests that shows I have a solid foundation. (And I didn't screw up somewhere). 😄
– Thanks for the mention, Denis & Adrian! 👍
I'm one of those (of MANY!!!) who (almost entirely) DO NOT make a list of tests before starting a TDD session. And I learned this from members of the C3 project, where TDD was found/created/developed. Sure, traditional development approaches have always advocated "First, Make a Test Plan." But many of us have found that TDD works well, in practice, without much up-front thinking or planning. Most of the thinking, design, etc. happens during the Refactoring step. So it often turns out to be premature to do too much up-front.
(Extreme Programming, as a philosophy, is generally "anti-up-front" in a number of ways -- planning, scheduling, documentation, etc.)
A useful guiding heuristic is ZOMBIES:
Z – Zero
O – One
M – Many (or More complex)
B – Boundary Behaviors
I – Interface definition
E – Exercise Exceptional behavior
S – Simple Scenarios, Simple Solutions
https://blog.wingman-sw.com/tdd-guided-by-zombies
The "zero, one, many" is where I suggest "First, ask for the song for ZERO bottles of beer on the wall.", and then "ONE bottle of beer", and then "TWO bottles of beer", etc.
An addition to the show notes.
Bryan also mentioned Liz Keogh as a great practitioner of BDD ideas and practices:
https://www.slideshare.net/lunivore/behavior-driven-development-11754474