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

81–86 of 86 posts

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

#81

Post by hbrn »

notaspecialist wrote: post #67

In all my years of coding, I only knew one developer who did TDD properly. He taught me, as I was struggling trying to track down an intermittent bug and nothing was working. Not going to lie -learning to do TDD properly is difficult. Since learning it, I've not met another dev who does it, and most devs barely write tests. Stick with it, practice. You'll eventually hit that ahah! moment. A story: I used to work with…

> Not going to lie -learning to do TDD properly is difficult

> The dev manager had everyone take a day of TDD training after that, but nobody really understood

That is exactly the problem with TDD or any other methodology that is hard to get right. Methodology will either push to a pit of success, or a pit of despair. If it's hard to get right, pit of despair it is.

Force 100 people to do TDD. 95 of them will be harmed, 5 will succeed. Same if you do waterfall. Same if you do Visual Basic. Same if you don't do code reviews.

TDD is indistinguishable from any objectively malicious practice. Somehow the fact that few folks were able survive TDD, is twisted to present TDD as some kind of holy grail.

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

#82

Post by fedeb95 »

gremlinsinc wrote: post #58
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…

yes if you have tables -> DTOs -> REST services without much logic the need for TDD beyond endpoints (I don't think it can be called TDD at that point) is limited. If you have services with lots of logic though... it could be useful to test that logic, if it's critical to business. Or if you deal with a framework used by different projects with different requirements, and/or if your software relies a lot on external configuration. Then features can (and will) clash so having some tests that detects those at different layers (unit, service, e2e, etc.) is good. Why TDD? Because it builds a system designed to be covered by tests. It's way harder to introduce tests later in critical parts of the system. This is textbook and in my experience also true. Again, different needs make TDD and automated tests more or less useful.

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

#83

Post by mbrodersen »

softwaredoug wrote: post #13

Use whatever feedback loop is most efficient (speed / accuracy). Sometimes that's building a full app and getting it to market. Sometimes that's isolating a bug in a legacy system to a unit test. Sometimes its the compiler failing to build your code. Sometimes it's a data science problem, and it means training a model in a notebook, to measure its accuracy. Don't get hung up on using one particular feedback loop. Get…

100% agree. The faster you can make your feedback loop, the more productive you will be. That’s why automated tests can be a super power. But only (as with everything else) when done right. So how do you know you are doing it right? When your automated tests save more of your time than the time it takes to maintain them. It’s really that simple.

In my experience I get those benefits when testing at the system/use case level but not when doing unit tests. At that higher level automated tests works wonderfully. I haven’t had a bug in production for 5+ years because of test automation. Which means that I spend 95% or more of my time adding new features or optimisations instead of bug hunting and/or getting shouted at because of customer problems. Love it!

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

#84

Post by mbrodersen »

jodoherty wrote: post #29

Don't think in terms of tests -- think in terms of examples. Write examples of how you would like to be able to solve common cases and handle edge cases if you had the ideal interface based on what you know at the time, then use unit tests with stubbed out interfaces as a tool while trying to develop the implementation. Refine and even rewrite your examples as you learn about what works and what doesn't work. Recursi…

That’s a great pragmatic way to think about it.

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

#85

Post by mbrodersen »

malermeister wrote: post #37
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…

In my experience tests also slow refactoring down , despite the common mantra claiming the opposite. Want to extract some logic into a new interface or introduce a new parameter to a method? Well, now instead of just doing that, you will also have to update all tests dealing with said logic. At my previous job I spent much more time updating tests testing trivial shit than actually writing useful code.

Not my experience at all. I can only safely refactor major parts of the large complex C++ software I am maintaining because of the tests.

If you can’t refactor your code without breaking tests then your tests are testing implementation details and not higher level specification details. Your tests should test your use cases not your implementation details.

In other words, if you can’t refactor your code without breaking your tests then you are doing automatic testing wrong. It’s that simple.

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

#86

Post by dominotw »

kazinator wrote: post #35
ignu wrote: post #20

Earlier quoted context omitted.

That's very false in my experience, and I did 100% TDD for years (have a more nuanced approach currently in TypeScript/React) As a programmer with a problem, you first instinct is to start at the solution. TDD pulls you back, and you first have to write the api and decide how you verify it. If you're doing it well, you make both of those things as simple as possible, first. Reduce dependencies and inputs, etc. That's…

Even a string length api like len(s) is not exhaustively testable; you can't prove it correct with blackbox tests. TDD has refactoring steps which only have to preserve passing tests; refactoring can easly be the vector that introduces dead code as well as changes behavior for untested input combinations. I suspect that a lot of code developed TDD is actually deployed on input combinations that are not covered in the…

> Even a string length api like len(s) is not exhaustively testable;

But this has nothing do with what GP said. That isn't what gp is using TDD for. GP is using TDD for,

1. starting with api of a function vs code.

2. avoiding unused lines of code

3. reducing dependencies, its hard to tdd something that has a lots of deps so it drives your refactor it something more testable and thus more readable/maintainable also.

4. simplest set of input/output.

Post reply on HN