Suppose that you want to build an web app using TDD…
How do you start?
Maybe you have done some projects adopting the use of unit testing... But coding first and then unit testing.. And then at some point of the development process, it became quite natural to use a test first approach.
Now you would like to make the next step and try to start a new project with TDD from the beginning... But here is the problem... How do you start?... How do you write your first test when you have no code at all?
What is the right level of abstraction?
The concepts around TDD are not that hard... Make a tests, watch it fail, write some code to make it pass... Make a test, watch it fail...
But what is the right level of abstraction?... Where should you test?... Is it a class, a method, a "controller", a "model", a web server... All of them?
... People always talk about "unit tests" and "integration tests", but every person has a different definition about what a "unit test" or an "integration tests" is.
Should you decouple your tests from the database?
Some people recommend to decouple your test from the database... But which tests should you decouple?
Have you followed this advice and just felt that you where testing nothing
Have you avoided this advice ending with a really slow test suite, that you don't want to run.
Should you do end-to-end tests?
Also is a common practice to use end-to-end tests in the TDD process... Is this the right way to do it?
Some people do it this way, because they feel secure and confident, and that's a good thing!
Other people have use this approach, but they hate it, because their tests suite keeps getting slower and slower!... Then they start testing less and less, and the confidence starts to go away =(
Do you have this questions in your head?
Do you know how to answer them?
Do you feel confident about your answers?
Well, this questions are hard to answer... And you will hear all the time opinions that can contradict each other, because some things work in some situations and some in others. Some people like things that other don't.
But, even knowing that... Sometimes the uncertainty can be frustrating and really slow you down. And is better to have an opinion and just start!
Wouldn’t it be nice...
To just have an approach that can let start and modify your decisions later!
To just know how to start each new feature using TDD and really feel confident about your code.
To be able to support design decisions are with fast tests that allows you to refactor and change your design when you feel is needed.
To finally adopt an style and design guide, that will help you to really start getting that TDD rhythm… test, code, refactor… test, code, refactor…
Well, this book is here to help you get there...
Is an example of how you can build an app using TDD by focusing on the the requirements not in your model or what you think is the right design.
Is an example of how you can decouple your code from your tools and frameworks, to help you delay decisions to the moment, when you have more information to take them.
We are going to build an app using ruby and rspec and we will deliver the application as a web app using the Sinatra web framework, although this last part will be just a detail, and you will be able to port the knowledge to Rails or even other languages.
We are going to build it really spec by spec, you are going to see each falling tests and the reason of every design decision.
And you will find code not definitions...
Shall we start?