TDD

Recorded live on twitch, GET IN

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))

[Flameandfireclan]

“ADD (Anger Driven Development)”. The chat is spitting bars

[ristopaasivirta]

TDD allows me to dictate impossible tasks and leaves me more time to grind Path of Exile while the devs struggle to meet the specifications.

[jamsky]

TDD walks into a bar and asks for 1 beer, 9999 beers, -1 beer, #$y& beers.
Customer interface walks into a bar and asks for the toilet.
The bar is set on fire.

[ShikaIE]

Not only you’re gonna feel awful integrating them, you’ll also waste a lot of time rewriting tests when you realise the implementation is not gonna work when integrating.

My workflow for doing something new is always quick poc with quick codes, then refactor with TDD.

[larryd]

TDD is not "write all tests upfront".
It is "write one positive test for what you think it should return, then implement it".
If you are wrong change the test and correct the implementation.


I don't get the hate it receives. I really like having a set of checks, which prove me that nothing broke, when I restructured something or renamed something. It's like the OG CoPilot.

[taestott]

Ever since Return To Office one of my coworkers coined the term "Location Driven Development" 😂

[robertluong]

I like outside in TDD where I start with an e2e test and work inwards. That being said, yes, it mainly works when you know what you're doing. For exploration and experimentation, you're spending much ado about nothing.

[CaimAstraea]

I kinda gave up. The specifications keep changing and ended up spending more time fixing tests every day than doing actual work.

[RichOrElse]

TDD is a habit, if you are not used to writing good specs, it will slow you down.

[CalifornianViking]

Automated unit tests are great when you have something to test. TDD messes with the creative worflow when there is no interface specification.

[ward]

Sounds like the guy was describing BDD (Behavior Driven Development) with that "exploration of the interface".

It's very tough to even do BDD if you don't have your plan ready for 90%, TDD also requires you to understand the domain before you write anything.

[orlovskyconsulting]

no, no, you use TDD as design tool! IF you cant came up with good design its up to you not a problem with TDD

[JustMe-lptd]

I think people misunderstand TDD. like how can you know if your code works unless you run it? tests are just there so you know it works without having to build the whole system, so you can iterate faster. Then you build the whole system XD.

[sorcdk]

Another problem with TDD is that it kinda forces you to built things top-down, which has its own issues. Sure designing an architeture generally works better in a top-down approach, but I find that actually writing code and solving problems tend to work much better in a bottom-up approach done after your top-down designing phase. That you generally know what kind of problems you need to solve from the design phase, so the pieces you built bottom-up as solutions to those problems are much more adaptable to the changes to the design you are very likely to need to do, whereas if you built things in a top down way, then the form of your solution processing components are more of "I want something that makes this line nice", which puts a lot of extra form and restrictions on the inner part that really did not need to be there and which adds to the complexity of figuring out and writing down the solution to that given problem. It is also much more prone to just needing to be deleted when something goes wrong.

Think about it this way, when building your structure of components and putting them together they work kind of like a tree, and there is a far greater amount of end components than there are big nodes putting them together (with something with more than 2 branches per node), and in a top-down approah a failure to build one of the end points cascades back to its parrent node, as it needs to come in a different format, and possibly cascade even further up, and most of the children of such nodes will no longer work either, because the needs from their parent have changed so they no longer fit. This means that just one failure can cascade into a ton of code that needs to be reworked. In a bottum-up approach a failure generally happens more often at the nodes levels or a node needing something different from its children, but in either case you have fairly isolated escalations, because it is either just that node or the problematic child that needs to be rewritten. This means that as the problem you want to solve gets larger and larger, then you get a larger and larger chance that you have to throw more and larger parts of your code away when you eventually hit a problem. With bottum-up construction, you can keep such things down, and it becomes more feasible to attempt to solve larger problems.

Now you could do TDD on those smaller components, but the trick here is that for these components the actual interface absolutely does not matter, as it becomes whatever is the most convinient to link the different parts of your problem solving together. This also means that TDDs fixing of that interface puts in extra constraints that barely have any reason to be there in the first place.

Overall I find that it generally makes the most sense to do TDD when you have an outside defined interface (such as when the jr gets told they need to deliver this thing by the seniors or an architect), or in other special situations when someone does have good knowledge of how to structure the problem, such as when mentoring someone, where the mentor can guide the tests and interface to make the mentee explore the posible solutions, but guide in the right direction by that early setup. In fact I find that the fact that I can use it that way to mentor other people also mean that that early form of interface and test lockin means one would also lockin how they think about the problem, which can then create a host of issues later down the line. This is how that problem with needing to understand the problem domain and the interface that primeagen talks about comes in, because it is especially problematic when you have problems there, because it is the likely flawed understanding of those that gets locked in so early and becomes much harder to move away from, if you use TDD on such projects and at full scale.

[vrongmeal]

Not here to defend TDD, but it’s better (99% of the times) that you have something good for testing compared to something thats way hard to test

[diegolealco]

TDD is a methodical and structured way of solving a problem; it does not interfere with creativity, it helps you articulate it.

The byproduct is a really good suite of tests which will end up saving you countless hours of work.

If lack of direction doesn’t kill a product, lack of good tests definitely will.

[eamonburns]

What I have been doing recently is
1. Write a function that works (barely)
2. Write tests that the (barely working) function passes
3. Write more test cases for the function as i come across them (they fail)
4. Rework the function so that it passes the new tests

(And what I mean by "barely" is that there are probably a lot of corner cases that will break it that i don't know about yet)

So I guess that steps 3-4 are technically "test-driven" because I am writing the failing tests first, and then fixing them

[relativisticvel]

TDD is good for fixing bugs. Make a failing test then fix the thing, so you know you are actually fixing what you think you are.

[Prime-of]

How can you start writing code without knowing the interface first?

[jonathansaindon]

What happens when you make the test after the implementation is that we often don’t have time to do it correctly. Also, TDD forces dependecy injection in your architecture.