tags:

views:

283

answers:

6

Hello,

I'm very new to TDD world. I have a few questions regarding TDD.

  1. Do I have to do test-first in TDD? I heard that TDD is not about test. It's about design. I'm agreed that it's good to do test-first but what I like to know is that is it still TDD if we follow the test-last approach?

  2. Shall we prefer to use BDD over TDD? I used to list out the specification of my task first and I try to write the test case based on my specification. Is it wrong approach? Do you guys prefer using BDD or TDD for your development?

  3. Mocking? Some people from my team used to say that they are praticsing TDD. But they never follow test-first approach. they never mock the data. Do we have to mock the data in TDD?

  4. "Using Mock Library" Vs "creating the mock class with data manually". Do you prefer to use mock library or create the mock classes with some mock data?

  5. Any recommended book for TDD or BDD? I read Kent Beck's classic Test-Driven Development - By Example. I found that this book is published in very early stage of TDD so some of the things in this book are not a bit outdated.

A: 
  1. Yes testing first is pretty much what TDD is.
  2. If you have no experience with either, I would start with TDD to get your feet wet (my opinion).
  3. You don't HAVE to mock to do TDD. However, if your application has classes which depend on other classes (which is pretty much guaranteed) you should come across mocking. BTW mocking is not about mocking the data, but mocking the interaction between the class you are testing and its collaborators, the other class(es) it is dependent upon.
  4. Mocking by hand is a good way to understand it but mocking / isolation frameworks is the way to go if you don't want to spend your whole time writing fake implementations.
  5. IMO, Beck's book is a timeless classic and a great way to start. If you work with .NET, I just read The Art of Unit Testing which covers in great detail good techniques and practices when unit testing.
Mathias
Thanks.. I had experinece in unit test and even develop one unit test framework with some custom features for QA team a few year back.. but yes. not tried to practice TDD in real project. when i start writing unit test before coding, I'm not so compatible with that. when I try BDD, it seems like something that I want. its more readable, know what to test (spec) and know when to end (spec).. hty,didn't go so deep in both TDD and BDD but I might be missing something in TDD.Do you guys really prefer TDD? Don't you think it's a bit weird to write unit tests more than what we have in spec doc.
Mark
It probably depends on the process in your team and the type of code you write. I usually don't have much of a spec to start with, so writing tests first isn't a problem, it helps flesh out what the specs are, and figure out problems. I found writing tests first very useful also in designing a system, because it forces you to "visualize" what you will create and think about how you would use it, as if it was already done. It helps focus on what your goal is.
Mathias
A: 

(I picked the easiest question to answer as I am not qualified to answer other questions )

Any recommended book for TDD or BDD?

Agile Software Development, Principles, Patterns, and Practices , by Robert C. Martin

Extreme Programming Explained ,by Kent Beck

pierr
thanks. What about for BDD? is there any book for BDD out in the market?
Mark
+1  A: 
  1. Yes, it is about design, but this design methodology does involve writing tests first. People follow this rule with varying degrees of strictness, but most people I know who practice TDD tend to believe that it's better to follow the rule.
  2. BDD has been described as TDD done right. The difference is minimal. Essentially BDD just makes the point about tests as specifications more explicit.
  3. There is a great deal of disagreement about the usefulness of mocks. I personally prefer to test interfaces, and I avoid placing expectations in a mock. That said, testing in isolation is still a good idea for a wide variety of reasons, not the least of which is test speed. There's nothing more annoying than refactoring a piece of code which still conforms exactly to the previous interface, having a fully-working end result, and yet all the tests fail because the expectations on the mock weren't met anymore. Bad mock usage results in testing of implementation details rather than ensuring that the work performed is correct.
  4. See #3. I prefer to just use a stub with no expectations or alternatively an integration test.
  5. Test-Driven Development: A Practical Guide by Dave Astels. Highly recommended.
Bob Aman
Thanks a lot. I will get "5.Test-Driven Development: A Practical Guide" then..
Mark
+2  A: 

1). Do I have to do test-first in TDD? I heard that TDD is not about test. It's about design. I'm agreed that it's good to do test-first but what I like to know is that is it still TDD if we follow the test-last approach?

Yes! Strictly speaking TDD is Test-Driven Development. So the development is driven by the test. So you test first, then develop program to pass all tests.

2). Shall we prefer to use BDD over TDD? I used to list out the specification of my task first and I try to write the test case based on my specification. Is it wrong approach? Do you guys prefer using BDD or TDD for your development?

I think you should balance them. Use other technique to provide overall design first as best as time provide (do risk management to find appropriate time you should spend on designing) (Find a paper about "RUP essential". It give quite a good idea about balancing agile and less-agile). Identify the most critical parts then creates test and develop to pass the test.

3).Mocking? Some people from my team used to say that they are praticsing TDD. But they never follow test-first approach. they never mock the data. Do we have to mock the data in TDD?

Test-first and mocking is not the same thing. Mocking allows code to be more testable as well as be testable when other part (which this code relies on) does not exist. So if there is no such dependency (IF!!), then you can to not mock them. (Read "Working Effectivelu with Legacy Code" about Seam point for more details).

4). "Using Mock Library" Vs "creating the mock class with data manually". Do you prefer to use mock library or create the mock classes with some mock data?

I think it just like using someone-else library or create yourown. Totally depends on the situation and many factors. For example, if you project is big and you can find appropriate mock library, use it.

5). Any recommended book for TDD or BDD? I read Kent Beck's classic Test-Driven Development - By Example. I found that this book is published in very early stage of TDD so some of the things in this book are not a bit outdated.

There are list of books on TDD here.

Hope this helps.

NawaMan
A: 

Do I have to do test-first in TDD?

Yes, TDD is necessarily test-first. Writing the test first allows to think about the function to be written in terms of behavior, rather than of implementation, focusing on invoking the function and verifying the result. This leads to testable code ; otherwise you may find yourself in a dead end.
Writing tests first also make it easier not to forget or neglect tests.

Moreover, writing - and failing - the tests first allows testing the test. A test written after the code might never fail.

Shall we prefer to use BDD over TDD?

Some say BDD is TDD done right as the focus is put on specifications.

Do we have to mock the data in TDD? Some people from my team used to say that they are praticsing TDD. But they never follow test-first approach.

You don't have to use mock objects. There are just a tool, that can be convenient sometimes.

"Using Mock Library" Vs "creating the mock class with data manually".

I never felt the need to resort to a mock object generator.

Any recommended book for TDD or BDD?

TDD by example, is a very good tutorial and presents a bunch of patterns. Another great book, more a reference is xUnit patterns.

philippe
+1  A: 

Do I have to do test-first in TDD?

Yes, TDD is, in essence:

vagueness -> bullet points -> tests -> code

If you are using some other process, it can make sense to use some of the tools and techniques, but it won't really be TDD. For whatever that is worth.

Mocking?

There are 4 more or less viable alternatives which different gurus will advocate.

  1. mock-to-zero: mock every dependency such that every unit (e.g. java class) is effectively isolation tested.

  2. mock-to-linear: mock cyclic dependencies only, such that there is a linear ordering of tests whereby each unit is tested only with tested dependencies.

  3. mock-for-speed: only mock slow, asynchronous or otherwise problematic interfaces.

  4. zero-mocking: just test stuff, use a debugger to work out what's going on if things break.

Avoid #1 if you don't love your mocking tool, and avoid #4 if you don't love your debugger.

soru