I read a lot of question and answer on TDD and unit testing on SO but I found nothing that answer to that: where do I start from?
Me and team already done a couple of project in which we adopted the use of unit testing, for our code… but code first and then unit testing. At some point of the development process, it became quite natural to write the test first and then the code, bringing us to a more TDD style.
Now we would like to make the next step and try to start a new project with TDD from the beginning. Here’s the problem… where to start from? Which is the first test I’d write when I have no code at all?
Let’s say, just to have a context to think about, that I have to develop an internet application, document-centric, with a little work flow and… something else.
But let’s start from the beginning: first thing, I want to create a simple page that list all the document (metadata) stored in a table on a DB (quite simple, uh?).
Which is the first test I’d write? Let’s say that I’m using Hibernate to access the db… would I test the ipothetical method getAllDocuments()? But should I use a mock object to substitute Hibernate? So what am I testing?
I’m a little confuse here… moreover the getAlDocuments() probably will never be a production method… all the collection of documents will be ordered and filtered by something… does it make sense?
Any suggestion will be appreciated
Edited:
After reading your answers (and the similar thread at http://programmers.stackexchange.com) I come with a better vision of TDD, but I still have a dubt.
I always though TDD is about making unit test first… never thought about end-to-end test.
But let me ask: TDD say you have to write a test and see a compilation error; then you create class and method and you get a test failure; then you implement the method and get the test passed. You cannot write code until there’s a test that fail; you cannot write another test until all test pass. Am I right here?
How can I make an end-to-end test as my first test? I should write all the code, in all the layer, to let that test passed. But then I’ll have a bunch of classes and methods all tested by my end-to-end test (shouldn’t I call it integration test though?). This means I won’t need unit test anymore, because I already have a test that cover my code. And I can’t write a test that pass already, it’s against TDD pratice.
Help me understand this further step ahead please
TDD is not about unit testing – TDD is about driving your development and architecture with tests – with any type of automated tests you need. Do you see the point?
You are starting a new project and you probably have a set of features. You should have some acceptance criteria for features you are going to implement. These criteria can define your top level tests. Let’s start either with an end-to-end test (this can be quite hard sometimes because it involves UI which doesn’t exist yet) or integration test for these acceptance criteria. Once you have test which is failing you will continue to implement features related to the large test but each this feature will be again driven either with an integration or an unit test. The feature is completed if all top level tests pass.
If you skip large tests (end-to-end, integration) you will develop set of well tested units which will either do not work when integrated together or your architecture will not be very good because of local scope defined by unit tests. Integration and end-to-end tests give you a global scope.
This is described with large example (Java) in the book Growing Object-Oriented Software Guided by Tests.