Hacker News Reader

Comment by tbrownaw | Hacker News Reader

> Tip #1: Write the tests from outside in.

> Tip #2: Do not isolate code when you test it.

> Tip #3: Never change your code without having a red test.

> Tip #4: TDD says the process of writing tests first will/should drive the design of your software. I never understood this. Maybe this works for other people but it does not work for me. It is software architecture 101 — Non-functional requirements (NFR) define your architecture. NFR usually do not play a role when writing unit tests.

The one time I ever did "proper" red/green cycle TDD, it worked because I was writing a client library for an existing wire protocol, and knew in adance exactly what it needed to do and how it needed to do it.

Item 2 is right, but this also means that #1 is wrong. And knowing what order #2 requires, means knowing how the code is designed (#4).

View on HN

The tips are not contradictory if you follow the advice to start at a higher level.

Let's say you had to invent that wire protocol. You would write a test for a client that doesn't care which wire protocol is used.

TDD works great for this. Usually before I am sent a new piece of equipment (has to go through the approval/purchase process) I’m given the docs. I’ll write unit tests using the examples in the docs (or made up examples based on the docs). I’ll write my software controller against that. By the time I get the actual device I’m just confirming my code works.

TDD was later given the name Behavior Driven Development (before being usurped by the likes of Cucumber, Gerkhin) in an attempt to avoid this confusion. TDD advocates that you test that the client library does what its public interface claims it does – its behavior, not how it is implemented under the hood. The wire protocol is almost irrelevant. The tests should hold true even when the wire protocol is replaced with another protocol.

Do you have any references that BDD was used as a term before Cucumber?

Search for the writings of Dan North, and don't forget that in the English alphabet, "Behaviour" is spelled with a "U".

Very roughly, Cucumber framework appears in late 2008? Whereas BDD first appears in the TDD community no later than December 2005.

Ex: here Dave Astels references a BDD talk he presented in 2005-09: https://web.archive.org/web/20051212160347/http://blog.davea...

I suspect it goes deeper than that, which is some of the confusion.

If you have multiple layers/parts some will treat each part as an independent library to be used; Implementation details of one level are depending on public interfaces of the next level.

That's not quite right, historically.

Behavior Driven Development began as a re-languaging of TDD: "The developers were much more receptive to TDD when I stopped talking about testing." -- Dan North.

BDD diverged from TDD fairly early, after some insights by Chris Matts.

As for TDD advocating tests of the public interface... that seems to me to have been more aspirational than factual. The tests in TDD are written by developers for developers, and as such tend to be a bit more white/clear box than pure interface testing would suggest.

In the edge cases where everything you need for testing is exposed via the "public" interface, these are equivalent, of course, but there are tradeoffs to be considered when the information you want when running isolated experiments on an implementation isn't part of the contract that you want to be supporting indefinitely.

Reply on news.ycombinator.com