"Zero Iteration" - end to end acceptance test in simple contact-form feature

I was reading "Growing Object-Oriented Software, Guided by Tests" lately. Authors of this book sugested to always start developing a feature with an end-to-end acceptance test (before starting TDD cycle) to not loose a track of progress and to make sure that you're still on the same page while unit-testing.

Ok, so I've start writing a veeeery simple application in python+django just to try this approach out. I want User to be able to ask a question via contact-form, the question should be then stored in a db, and a si开发者_JS百科gnal after completion should be send to notify mailer which will send follow-up message.

Question is - how you'd approach this first end-to-end test in this case? Do you have contain all possibilities in this first test, or maybe I'm misunderstanding this whole technique.

Any examples would be most welcome.

---

You don't have to contain all possibilities in acceptance tests at all - you will still write unit tests. So I would say that a single tests "user can fill in the form, save it and load it back" is enough to start with. Then you can add more tests if you think that a particular aspect of your system is important enough that it needs an acceptance tests. Don't worry about handling all possibilities here, you will still write tons of unit tests where you will test everything!

The easiest way to start is to grow your acceptance test in parallel with the code: so start with testing that the user can input data, implement it until it stops failing, then add to the test the condition that the user has to load this data back etc. It will take a while to implement the initial infrastructure for the acceptance test, before you even start writing production code, but you can't escape from it anyway, and there are various benefits to have tests upfront.

---

This use-case leads to several test-cases (every tests a dedicated possible path of execution).

When writing tests focus on one possible outcome, after a while test-suite grows. The first tests then also give you safety net as regression tests to not break anything which you already implemented successfully.

My first tests would be:

• Happy path 1st part frontend-form + controller layer: User passes correct data, controller take the form and log to console/stdout
• Happy path 2nd part: Instead of logging to stdout, things get stored to database
• Happy path 3rd part: Follow-up mail gets sent and received by User
• Validation error handling (user fills form out incorrectly, e.g. misses mandatory fields, wrong email-pattern)
• ...

Fill out the rest ;) Depends on the more detailed requirements...

Remember to implement above as simple as possible. When all tests are in place, refactor ruthlessly to make "internal quality" nice.