Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Seriously, how do you TDD?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Ask HN: Seriously, how do you TDD?

#51

Post by avl999 »

Only the most religious TDD evangelists will force you to "drive the design" using tests. That advice is not relevant for most developers except for perhaps absolute beginners who don't have the experience or mental models to determine what a good design is and TDD might force them to come up with a decent design by the sheer fact of making their design testable, which alone goes a long way (but not necessarily all the way) in making a "good design".

Most experience developers will come up with the architecture/design of what they are working on through a combination of intuition and experience, write tests after and then use TDD to fill the gaps once they have nailed down the architecture.

I do TDD some of the time and my workflow often look like this:

1. Start implementing an object/class, defining APIs of its key methods while having a higher level picture in my head of how it will fit with other components

2. Implement a good chunk if not all of that object (not more than a few 100 lines typically)

3. Write a test to verify that what I did worked.

4. Start commenting out parts of the code I wrote to make sure the applicable test cases fail. Uncomment after verification is done.

5. Use TDD to cover and implement edge case handling and anything leftover

6. Repeat 1-5 for each class/component/module until done

I only get into TDD once the architecture and high level design are finalized, and I have some code written for them and I have some reasonable level of confidence that it is not gonna drastically change. I also generally go "bottom-up" starting from the leafs of the object graph up and use TDD maybe ~50% of the time (just a rough guess).

Trying to force yourself to let "TDD drive the design" will likely result in frustration as you have experienced and slowdown.

Re: Ask HN: Seriously, how do you TDD?

#52

Post by bjourne »

I get what you mean with the tip of the iceberg analogy. The problem is that you can't write any insightful tests before you have written the structure of the application and you can write the application before you have written the tests cause of TDD.

So what I do is that I first hack out the application before I write any tests. E.g if I code a matrix multiplication routine I'm not going to waste time writing unit tests for it. Cause perhaps a few hours later I might realize that I don't need matrix multiplication after all. An added benefit is that I don't have to constantly "context switch" between test writing mode and implementation writing mode.

I write tests when I have something interesting to test. So if the application unexpectedly crashes when I run it I write a test that triggers the crash. Then I fix the bug which causes the test to pass. I find these types of tests to be much more valuable than the "cookie-cutter" unit tests TDD expects you to write.

Re: Ask HN: Seriously, how do you TDD?

#53

Post by avl999 »

hbrn wrote: post #33
windows2020 wrote: post #25

A year into a novel project, a teammate expressed their concern about a lack of unit tests. They'd even spent time creating a bunch early on. I asked if they still ran or were even relevant any longer and the answer was no. Particularly with exploratory projects, I'd recommend focusing on rapidly iterating to reach the simplest solution (businesswise and implementation-wise). If in the end non-trivial logic must be s…

There's this stupid dogma: tests are good, codebase without tests is bad. It is incredibly hard to fight the idea of "we need more tests" because of that. Anytime engineering team gets some freedom, tests are usually the first thing they decide to work on. But tests aren't inherently good. Good tests will speed you up, bad ones will slow you down. And it is incredibly hard to write good tests. Might be even harder th…

Software isn't written once and left to run in production for it's lifetime, it is constantly being iterated on and changed. And a lack of tests will inevitably result in a slowdown of the rate you introduce new features as now you need to spend longer convincing yourself that the change you made didn't inadvertently break something else (plus rolling back and outages that will result from such an event).

Most tests written by people working on the product will of some baseline level of quality and even if they weren't, even if they were "bad tests". It is much easier to fix bad test than it is to deal with an application on a day to day basis which has no tests.

Re: Ask HN: Seriously, how do you TDD?

#54

Post by thiht »

I use TDD only when fixing reported bugs. First I write the test for the expected result, see that it fails, fix the code and check that the new test passes.

TDD as it’s supposed to be done according to evangelists doesn’t work. I have the same problem as you every time I try TDD for implementation, and the answer I get is always that I’m doing it wrong somehow. I have better results without TDD in these cases though.

Re: Ask HN: Seriously, how do you TDD?

#55

Post by _tom_ »

ris wrote: post #48
bitwize wrote: post #32

Earlier quoted context omitted.

The way to do it using TDD is to do your greenfield development to the point of a working solution to elicit your fine-grained requirements, then throw that away and rewrite it using TDD. The first version is considered a "spike solution" and is not supposed to touch production. In TDD, all production code must be written against some pre-existing test. Any code which does not meet this criterion is broken.

I have never worked with that sort of time luxury.

It's frequently faster. Half-assed designs will cost you time forever.

Re: Ask HN: Seriously, how do you TDD?

#56

Post by hbrn »

avl999 wrote: post #53
hbrn wrote: post #33

Earlier quoted context omitted.

There's this stupid dogma: tests are good, codebase without tests is bad. It is incredibly hard to fight the idea of "we need more tests" because of that. Anytime engineering team gets some freedom, tests are usually the first thing they decide to work on. But tests aren't inherently good. Good tests will speed you up, bad ones will slow you down. And it is incredibly hard to write good tests. Might be even harder th…

Software isn't written once and left to run in production for it's lifetime, it is constantly being iterated on and changed. And a lack of tests will inevitably result in a slowdown of the rate you introduce new features as now you need to spend longer convincing yourself that the change you made didn't inadvertently break something else (plus rolling back and outages that will result from such an event). Most tests…

> lack of tests will inevitably result in a slowdown

This is exactly the mindset I'm talking about. Lack of which tests? Manual? Unit? Functional? Integration? End-to-end? Doesn't matter, right? All tests have zero cost, the more the merrier.

And when exactly does the slowdown happen, on day one? Or maybe some time in the future? Do we have a way to tell when exactly should we write tests, how many, and which ones? Most of the time the mindset is "we don't have tests, therefore we need tests". Cargo cult at it's finest.

> Most tests written by people working on the product will of some baseline level of quality

Not in my experience. Tests are often introduced before you have a good understanding of the domain (hello TDD). Epitome of that is hiring junior engineers, realizing you don't want to assign any real work to them, and forcing them to write tests.

> It is much easier to fix bad test

Typically bad tests should not be fixed, they should be thrown away. But pretty much every company sucks at deleting bad tests, because there's the illusion of value they provide.

Re: Ask HN: Seriously, how do you TDD?

#57

Post by Waterluvian »

When I was newer I tried it as a hard rule and it sucked. So much wasted time and silly tests that didn’t test anything interesting.

Now I have a sixth sense for what I should write tests for and when I should write them before vs after the implementation.

Rules are misleading and teach the wrong thing. Instead, here’s one loose question I ask myself: “does the interface inform the implementation or the other way around?”

When the interface is super important and known, I can write a test first. When the implementation will reveal what the interface’s shape might be like, the test might come after.

Re: Ask HN: Seriously, how do you TDD?

#58

Post by gremlinsinc »

fedeb95 wrote: post #42

Read about AMDD. The idea is: you not only write tests to design and iterate on that, but also sketch a model of your system and iterate that. Depending on the size you may want to sketch subsystems, etc. Now the only problem I have with TDD is time. It takes a lot of time to do it right and usually I don't have that time (in my organisation). So maybe you can tdd some parts of your application, maybe the most critic…

I do a lot of rest api's, and generally, I just manage to test endpoints and data/json structures adhere to design specs or DTO's or typescript types, etc. I'm usually dealing w/ laravel but there's packages to translate backend DTOs to typescript types, for frontend devs to mess w/.

As long as all the restful resources work properly and get an expected outcome, there's a good chance everything else should work fine too.

Re: Ask HN: Seriously, how do you TDD?

#59

Post by gremlinsinc »

itrollpussies wrote: post #26

I am not trolling today, TDD doesn't make any sense to me, testing to fail and correcting it until it passes doesn't work with my flow. In a DAW(Digital Audio Workstation), this is like adjusting the knobs, adding effects when you haven't even added any samples, it just doesn't make any sense, stop forcing yourself to do things that doesn't align with your flow, you'll likely get annoyed for no reason. The way I work…

Is there a specific tool you use to figure out your design graph, or is it more a 'mind' thing? I know there's some vscode plugins to kinda visualize how code fits together, etc.

Re: Ask HN: Seriously, how do you TDD?

#60

Post by teddyh »

> Before that one, I tried the opposite: a more “bottom up” approach. I know I need to, at least, read a CSV, parse a CSV row into some data structure and then categorise it. So I TDDed my way through to complete these “sub problems”. However, when I was about to apply the categorisation rules I realised that the data structure I created didn’t help, was just bad and didn’t work at all :).

I think what would have worked for you is to write a test for the categorization, but feed it pre-parsed data structures in the tests. If the data structure is wrong, you will find out now. After that works, you have decided on a correct data structure, and you now can write code to read and parse CSV into those same data structures.

It’s all a matter of practice. If you do things in the incorrect order, these things can happen.

Post reply on HN