Do you really have to do BDD/TDD in a test first manner?

Question

Even though I haven't been in a TDD or BDD project, or I have been in some that say they are doing TDD but are pretty far from it, these are things that I think about and really try to read as much as I can about.

Back to the question. When you're doing BDD you should write your "test" first and make it fail, right? And then implement that feature or what you call it. But if you take this to the extreme couldn't this be some kind of top-down development? You're looking at your UI and says, "I would like to have this feature/behavior here". Then you fix your UI to implement that feature and the code that supports the UI. At this point you haven't implemented any business logic or data access logic, you have just implemented your behavior. What I'm aiming at instead of writing the test first you write your UI code first. In some cases it should result in the same code for the data access and business layer, since you use your UI code to define what your business needs to support.

Of course you should complement this with tests that is used to make sure that the feature is working as it should in the feature.

Any thoughts?

UPDATE: Good answers and thoughts from everyone I think. Some of you have stated, in one way or another, that you need to write your test first otherwise it is development-driven. I definitely agree with that when talking about TDD, since your test should drive your development. But when talking about BDD I'm not as sure that you have to write your test first, isn't BDD all about defining your behavior first? I think that looking at the UI and say: "hey I want this behavior/functionality here", sound quite behavior-driven to me. I don't say you should skip all your test but you could use the top-down approach as the first step as defining your behavior. I do think that when you have taken that first step and maybe implemented the feature in the UI with some mockup data you should start defining your test that verifies that behavior.

Answer 1

You are talking about BDD from a high level perspective of testing your UI. Testing is a bit more fluffy at this level than lower down in your Javascript/server side code.

Several books I've read on TDD say you should write code as if the underlying systems exist, and just write enough to get your test to pass. You can write stubs on the server to get your UI behavioural tests pass. Then you start at this stub seam and write some unit tests for your server side code and work your way down to a full implementation.

I often code as if underlying layers exist to get a high level test to pass, it does feel like going down a rabbit hole and extracting many other classes to satisfy the high level test, and then writing tests for these lower levels. As you've already recognised, it helps to keep you focused starting with higher level tests.

As any seasoned programmer knows, there are many layers to software development. I tend to work lower than the UI and think about the data or behaviour my UI needs from the server and start there (maybe because I don't do much UI work these days).

If I'm really honest, extracting a class from the underlying layers means I'm not doing test first but ... within minutes or sometimes hours I'll have a test for that code. This still feel beneficial to me as I helps see where you might need to supply dependencies to a class and honour the single responsibility principle - if it's hard to test, you're doing too much in one place etc.

Answer 2

If you don't write your tests first you are not driving development through your tests. Ergo, you're not doing test-driven development!

Answer 3

Yes! Otherwise, what you get is development-driven testing.

Realistically speaking, however, there are problems that are hard to approach by using "pure" TDD. You could be more productive writing by writing some uncovered production code up front and covering it with tests later (and learning how to approach similar problems with TDD in the future). Look at this technique, which its author called rinse-and-repeat TDD for want of a better term.

Answer 4

If you want to work this way, go for it. But it's not test-driven-development.

Answer 5

Personally, I believe that it is critical to think about testing during the design stage. Its really great having a working implementation, but the only way you can be sure that you have a working product is if you have tested it piece by piece. The way to cover this is by a combination of Unit tests and a skilled QA team working in partnership.

Now how you install this dicipline into your team is up to you. TDD is one such strategy - and one that has its place, and there are plenty of other variations. However, TDD is not particularly suited to developing UI layout.

Answer 6

What you describe sounds much like the Front-Ahead Design approach. Unfortunately, Front-Ahead Design is Alex Papadimoulis' satirical stab at agile methods.