Hacker News Reader

Comment by matthewfcarlson | Hacker News Reader

Yes, you're getting it exactly. This was for a personal project. The expected audience for it was my spouse and I and writing tests seemed like a nuisance. I don't even know why I started as getting the environment building in a testing harness was actually quite a bit of work. I noticed a benefit I didn't expect and wanted to share.

Did I not have a concrete idea of what TDD was when I wrote it? Yes. I had muddled test first development with test driven development as the two people I knew who were big on TDD were focused on TFD as they were refactoring large legacy codebases. I'm still murky on what TDD is (and it sounds like opinions differ) but I don't think I've discovered anything new. Just new to me.

View on HN

Even if you don't want to read Beck's book on it, TDD is ludicrously simple and still somehow greatly misunderstood:

1. Write a test

2. See that it fails (if it passes, you're testing a feature you already implemented or you're testing something you don't mean to be testing)

3. Make it pass (by changing the code, not the test, seen that too many times)

4. Refactor

5. Repeat

The catchphrase is "red-green-refactor". I don't know why people try and make it more complicated than that.

Regarding your post, just wanted to say that if you took my other comments as criticism of you they were not. Your misunderstanding of TDD is actually very common and I was intending to address that, specifically. I actual consider the fact that you both rejected the flawed TFD-style (and mass creation of tests that comes with it) and rediscovered TDD (the above process, more or less) both amusing and a positive thing. It shows you're doing what many others aren't, actually thinking and experimenting to discover techniques that work (at least for you and on this project).

>I don't know why people try and make it more complicated than that.

Given that the author of the term wrote a whole book about it rather than just tweeting those steps, I think over-complicating may be part of its genetics. Others are just continuing the trend.

---

For the record: yeah, short-cycle red/green/refactor fits how I like to do TDD. I don't know that I'd claim that it is TDD though - by far the majority I've run across take it to extremes, though of course my coding-exposure circle is skewed and may not even remotely be representative.

In that way, TDD sits in a very similar brain-space for me as Scrum does. Useful foundations, utter nonsense if taken to extremes, unsure if a net-positive influence (globally, not personally) in the end. I have seen a looooot of negative-value tests, in ever-increasing quantity as time goes on, in the name of TDD.

As a partial defense for the length of the book, it was "Test-Driven Development by Example". Hard to fit examples into the page or two needed to explain the core concept itself.

Letting ideas like this move into the "similar brain-space ... as Scrum" is dangerous. You're actively choosing not to think at that point, you're choosing anti-thought over thought. Move too many things into that brain-space and you're going to become thoughtless. Don't let that happen, you have more to contribute to the world than becoming another mindless automaton.

Engage with the idea instead, understand why it does or does not make sense to you. Why it is or is not applicable to some area. Why other people have different ideas about it or disagree on its applicability. You'll be much better for it. And as much as I also dislike Scrum, it's worth engaging with its core ideas as well.

I think you may be reading too much into my Scrum brain-space. Or maybe projecting?

I've looked at those things. Found what I think are the core valuable bits, and how they apply to me and my situation. And I do not want to interact with them in a professional setting, because they are almost always distorted beyond any reasonable interpretation of their core, losing all meaning of the term and being used as an excuse to continue bad behaviors. They're quite similar in that respect.

Step 1 is wrong, it should read:

1. Write a feature

2. Test it

When your feature is your whole app "I want to build a TODO list app", your test is "I can write a TODO list app".

When you inevitably can't do that (because you cannot write a unit test for this), you break it down "I want to open a window/app", test that "can I launch the app window", and iterate.

"and still somehow greatly misunderstood"

It misunderstood because its presented as a methodology involving some testing suite or library, then you're constrained to testing things that may have little to no value, like testing that classes have data on them, or that you call functions and they return data.

And considering (most) engineer's first contact is something like a "write unit tests for the class you wrote", its understandable that its seen as a mixture of useless (often is) and arcane (often is) instead of an extension of a methodology for creating and validating features.

The book A philosophy of software design https://www.amazon.co.uk/Philosophy-Software-Design-John-Ous... Points out that TDD can inadvertently lead to tactical design rather than strategic design. In my experience, this can be true. I'd never noticed until it was pointed out.

Im on a team that is currently attempting shift left. One part of this has been an argument that testers should review unit tests. I think this is not a good idea. Unit tests tend not to focus on the behaviour of system as a whole.

Reply on news.ycombinator.com