this post was submitted on 05 Aug 2023
19 points (100.0% liked)

Programmer Humor

32495 readers
679 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 1 points 1 year ago (1 children)

I like TDD in theory and I spent so many years trying to get it perfect. I remember going to a conference where someone was teaching TDD while writing tic tac toe. Unsurprisingly, he didn't finish in time.

The thing that I hate is people conflating TDD with testing or unit testing. They're vastly different things. Also, I hate mocks. I spent so long learning all the test doubles to pass interviews: what's the difference between a spy, fake, stub, mock, etc. Also doing it with dependency injection and all that. I much prefer having an in-memory database than mock what a database does. Last company I worked at, I saw people write tests for what would happen if the API returned a 404 and they wrote code that would handle it and all that. In practice, our HTTP library would throw an exception not return with a statusCode of 404. Kinda funny.

You obviously can't always get replacements for things and you'll need to mock and I get that. I just prefer to not use them if I can.

Also, TDD advocates love saying, you're just not doing it well or you just don't know enough.

I get it, you love TDD and it works for you and more power to you.

I definitely believe in testing and having resilient tests that will minimize changes upon refactoring, but TDD doesn't work for me for most of the work I do. It works for some and I love it when it does, but yeah .... sorry random long ramble.

[โ€“] [email protected] 1 points 1 year ago

After many failed attempts at TDD, I realized/settled on test driven design, which is as simple as making sure what you're writing can be tested. I don't see writing the test first as a must, only good to have, but testable code is definitely a must.

This approach is so much easier and useful in real situations, which is anything more complicated than foo/bar. Most of the time, just asking an engineer how they plan to test it will make all the difference. I don't have to enforce my preference on anyone. I'm not restricting the team. I'm not creating a knowledge vacuum where only the seniors know how yo code and the juniors feel like they know nothing.

Just think how you plan to test it, anyone can do that.