Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
The tests under TDD are unit tests, which drive the module directly, just as if it was through a separate main. In your top-down comment, you are talking about functional tests, which execute the whole program though a single main. –  Macneil Nov 30 '10 at 4:23
    
@Macneil: I don't talk about functional test that test the whole program, even thought you're implementing/designing your program top-down you should still implement unit test for all your public code. Just because you do it top-down doesn't mean you can't make different layers abstract so you can isolate all layers by itself. –  Tomas Jansson Nov 30 '10 at 7:33
    
@Macneil: This is a common misconception. TDD tests are not unit tests. TDD tests features, which have no set scale. –  Steven A. Lowe May 31 '11 at 2:24
2  
But there is a set scale: the test must execute quickly in TDD. There are tests that must occur that are also out of the scope of TDD. Overall, TDD is a development plan, not a testing plan. –  Macneil May 31 '11 at 4:20
    
@Macneil: "quickly" is a relative term. The test suite in my last project executes in about 30 minutes. It replaces 8 hours of manual testing. That is "quickly" enough! –  Steven A. Lowe Jun 2 '11 at 2:50
add comment

6 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
I think you are right. This got to me when I tried out ruby on rails this summer, there they have some bdd test that drives the UI which later drives the implementation of the underlying classes. –  Tomas Jansson Aug 19 '11 at 7:41
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
To be fair isnt the question more about whether when doing BDD (not TDD) whether we should be writing the test first? –  nashwan May 12 at 13:04
    
Feel free to substitute "test" with "behaviour". I haven't seen anything to convince me that, at heart, there's much difference between TDD and BDD. Focus, maybe. But the core idea? Not so much. –  Frank Shearar May 14 at 17:31
add comment

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.

share|improve this answer
3  
First line is awesome. –  EpsilonVector Nov 29 '10 at 15:23
    
Compared to TDD that is true, but doing things top-down should align pretty well with BDD, right? I look at the GUI and specify the behavior I want, sure I don't write the "behavior-test" right away, but I did specify the behavior throught the UI before I implemented it. –  Tomas Jansson Nov 30 '10 at 7:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.