11

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?

Improve this question
5
  • 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. Commented Nov 30, 2010 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. Commented Nov 30, 2010 at 7:33
  • 1
    @Macneil: This is a common misconception. TDD tests are not unit tests. TDD tests features, which have no set scale. Commented May 31, 2011 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. Commented May 31, 2011 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! Commented Jun 2, 2011 at 2:50

6 Answers 6

Reset to default
8

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.

Improve this answer
1
  • 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. Commented Aug 19, 2011 at 7:41
17

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.

Improve this answer
2
  • 3
    First line is awesome. Commented Nov 29, 2010 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. Commented Nov 30, 2010 at 7:35
15

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

Improve this answer
5
  • To be fair isnt the question more about whether when doing BDD (not TDD) whether we should be writing the test first? Commented May 12, 2014 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. Commented May 14, 2014 at 17:31
  • Disagree with the fact that you aren't doing test-driven development. You aren't doing it according to the definition of the keyed term, but as long as your are developing tests for your code, your code is definitely being driven by the tests, regardless of when you write them. Commented Oct 17, 2014 at 2:09
  • TDD specifically means writing tests before code. If you don't like that, take it up with Kent Beck, who invented the term. Writing tests after your code might drive your code to some extent, but you can still trick yourself into believing you're driving your code design through tests when you're not. And it's harder to write those tests, because you often have to change untested code. Seen it too often to mention. Commented Oct 17, 2014 at 22:38
  • @FrankShearar I acknowledged that its not TDD according to what Kent Beck said, but frankly I don't care about what some random person said. Its perfectly possible to drive code design through tests without writing the tests first. Commented Oct 18, 2014 at 14:09
4

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

Improve this answer
3

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

Improve this answer
1
  • I was wondering if you know of any articles that fight back at FAD, debunking its satirical stab? Commented Aug 13, 2015 at 8:07
3

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.