Hacker News Reader

Comment by juskrey | Hacker News Reader

I'm 17 years into coding and have never even tried TDD - just because it seemed horribly wrong.

I wouldn't call myself a regular practitioner of TDD but I can tell you that it's incredibly valuable in certain circumstances. When you're writing code that, for example, must be mathematically accurate, writing unit tests can be very useful just so you can assure yourself that you wrote the calculations down correctly.

They're also very useful for other "pure" operations. A factory should always produce an object with such and such properties. A user input validation method should always fail given some classification of invalid input, etc.

Hardcore TDD is definitely not The Way for me but it's very good to use at times. You'd be amazed how much it speeds up testing these kinds of processes when you can just watch your list of tests change from pass to fail or vice versa. As with anything, your mileage may vary.

I think you're confusing TDD with unit testing. You can unit test without TDD.

I'm not. I know you can do TDD without unit testing but it's very rare in my experience. I'm saying that the TDD cycle (write tests, run all and verify failures, write actual code, run all tests hoping to see no failures, refactor as needed until step 4 passes) works best when applied to unit tests. Integration tests, acceptance tests, and other "big" tests don't lend themselves well to that style of programming, in my opinion.

I think RyanZAG is saying you can do unit testing outside of TDD, not that you can do TDD without unit testing.

The fact is that both are true. You don't need TDD to use unit testing — you can implement first and test afterwards. In some cases, this may actually be preferable.

However, although TDD isn't a silver bullet solution, it can be very helpful in a lot of cases. Like with a lot of things, the usefulness of TDD depends on the situation at hand, and a good software engineer chooses the right development techniques for the job.

Unit testing of some sort, however, is considered good practice regardless of whether you're using TDD or not. (And of course, integration and acceptance testing is a good idea, too.)

> You'd be amazed how much it speeds up testing these kinds of processes when you can just watch your list of tests change from pass to fail or vice versa.

That sounds like a test-first strategy, which I would categorize as TDD. Yes, you can write unit tests without it being TDD, but I'll second the notion that the sorts of situations the parent pointed out benefit from a test driven approach.

Remember the mind map craze? For a few years, educators everywhere wanted you to do almost all learning by drawing circles with words and connecting them. For many people, this type of visual link between concepts allows them to learn far faster than regular textbook style.

For some people, mind maps make zero sense and they learn far slower. Some concepts just don't fit into mind maps at all and even for very visual people it just slows them down. There's often a more specific visual learning method for many problems than a simple mind map too.

TDD is mind maps. Give it a try, but don't feel bad just because mind maps don't gel with your brain.

I'm unfamiliar with the mind map craze. I'm familiar with them, we used the concept as a tool in grade school for writing essays and papers. I'm curious where and when it became dogmatic for some educators to push it beyond "this is a tool that can be useful, use it for some tasks and see how it works" to "this tool is the shit, mind map all the things".

Education is almost as cargo-culty as software development, with nearly as little empirical research being done to check the validity of the various schools of pseudo-religious dogma.

The only thing that has made me even more productive than TDD is functional programming/immutability (in conjunction with TDD).

You're basically wasting your time not doing it. If you want maximal productivity, learn TDD. Writing unit tests upfront is most definitely a case of "one step backward, two steps forward." Your code under test will be written better (which is to say, more modular/less cyclomatically-complex/easier to maintain and refactor), you'll break it far less often (from the same body of code or other code that relies on it), and you'll feel far more confident about your code. You won't be afraid to refactor it (afraid that you'll break something) because the tests validate it. It's also invaluable on teams, where not everyone is sharing the same mental model.

Speaking of which, remember that your mental model of the code is the true limitation. Unit tests allow you to offload some of that, so that you no longer have to have a perfect representation of all possible states your code can produce, inside your head (which if even possible would allow you to write perfect bug-free code). This is incredibly liberating. You can literally feel the difference. I know it sounds all touchy-feely to describe it this way, but so be it. But hey... If you can imagine every possible state all your code will ever produce at all times, you don't need TDD nor unit-testing, because you already know the "fails". ;)

And this is the other end of the spectrum, which is equally as bad. Don't be the guy who never tries new things.

Is it equally bad?

I didn't do TDD most of my career, product I delivered worked, where delivered on time and reached the goals set out by the business. Why bother? Because it's good practice? Hardly a valid argument in a business perspective.

"Business perspective" can be like hill climbing: you evaluate a potential direction based on whether it makes your situation more profitable or less profitable, regardless of the peculiarities of your local landscape.

I think got into TDD for its aesthetic or philosophical appeal. The idea of being able to make reliable software by first writing down what its supposed to do just struck me a poetic and tractable. On the one hand, I spent a lot of time and money going through a dip in productivity while learning all the things to make testing work for me. On the other hand, I eventually emerged from that dip with skills and a mentality that allow me to be productive and relaxed in a way that I wouldn't have thought was possible.

I use it because it's faster and it makes making changes later easier. It also allows me to leave the app mid-feature (happens a lot as I do more than just code) and comes back to it without having to load the whole app into my mind again. If I get my specs to pass then the app will work. Simple.

Most of my new things fail even before I write a first test for them.

What about it seem so horribly wrong to you? I'm by no means a zealot, and will often build things before writing tests, but there are definitely some problem spaces such as writing reusable libraries where going the other way round is a big help.

I can answer - most of the time I do not know at start what data structure/effect should be the exact result of my code, even if it is just a more complicated version of the "hello world".

In that case write higher level tests. TDD works best and provides most value when you go outside in. So your initial test would just determine that you expect to see "hello world" printed. Maybe on the next level down you now have to do some validation and you have to define how the interface (not used in the Java sense here) of the function or object or whatever looks that does the validation. The key thing here is that you don't need to think about how that will actually work on the inside, but how you want it to be exposed. As you start to TDD that portion of your code that implements that new functionality your tests shouldn't care too much about how the code under test is implemented, only about its outside behavior (this might include calls to other functions though that ideally get mocked). This process makes it easier to many practitioners to increment on functionality that they don't know in advance how to implement. That's why it's called "test driven development" and not"test first development".

All that being said, determining the right amount and granularity of tests is certainly much more of an art than a science and friends on the developer(s), what the system is doing, framework and the language you are using. I definitely write many more tests when I'm writing Ruby code than when I'm writing Rust. I'm also very new to Rust so we will see if that lasts.

TDD is also a bit weird in Rust since you can't do nearly as much of the dynamic tricks test frameworks tend to do. So I find myself writing less tests for this reason, or at least, different kinds of tests.

In TDD, you write the test to help figure this out. The idea is that you start with "how do I call this method/interact with this code/etc?", then ask yourself, "what should the result be?"

TDD is meant to help inform your design thinking, but there's no rule that says you can't change your mind as you go.

In particular, you should be changing your mind as a result of trying to write the tests. If it's hard to write a test, that's telling you something - the interface is clumsy to use, for example. TDD is different from just writing tests, because the tests drive development. "Drive" may be a bit too strong, but they at least significantly influence it.

Reply on news.ycombinator.com