Its definitely a bad idea writing new code that builds up on your old code, that has not been tested properly, because you quickly have to start debugging multiple layer is code at once.

you are viewing a single comment's thread
view the rest of the comments

[–] 9point6@lemmy.world 9 points 17 hours ago (11 children)

Honestly this is the reason TDD is most important for personal projects.

If it's your job, the code isn't getting merged without decent tests. Yes you should probably write them first so you think about your implementation properly, but let's face it, many tests are written after in practice.

If it's something written in your free time, you're just not writing those tests most of the time if you didn't write them up front.

[–] dejected_warp_core@lemmy.world 6 points 16 hours ago (2 children)

Writing the tests first, or at least in tandem with your code, is the only way to fly. It's like publishing a proof along with your code.

it sounds trite: make the tests fit the code. Yes, it's a little more work to accomplish. The key here is that refactors of any scale become trivial to implement when you have unit-test coverage greater than 80%. This lets you extend your code with ease since that usually requires some refactor on some level.

[–] ScintillatingStruthio@programming.dev 1 points 4 hours ago

Writing the tests first also ensures that the test actually fails when you expect it to. I've seen test suites that were silently failing for years because they were (presumably) written after the fact and people just assumed that they tested what they said they did. Went in for some other clean up, stared at the test for 10 minutes wondering "how did this ever pass", and then came to realize that test assertions in Jest inside a forEach apparently don't run in the context of the test and failures won't make the test fail. Changing the forEach to a for...of made it all fail immediately.

load more comments (1 replies)

load more comments (9 replies)