65
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 04 May 2024
65 points (98.5% liked)
Ask Experienced Devs
1064 readers
1 users here now
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
My team follows test driven development, so I write a test before writing the feature that the test, well, tests.
This leads to cleaner code in general because it tends to be the case that easy to test code is also easy to read.
On top of this fact, the test suite acts as a sort of "contract" for the code behaviour. If I tweak the code and a test no longer works, then my code is doing something fundamentally different. This "contract" ensures that changes to one codebase aren't going to break downstream applications, and makes us very aware of when we are making breaking changes so we can inform downstream teams.
Writing tests and having them running at PR time(or, before its deployed to production, if you're not using some sort of VCS and CI/CD) should absolutely be a part of your dev cycle. Its better for everyone involved!
Doesn't this rely purely on the fact that the test is right?
Yeah, but it isn't usually very difficult to write a test correctly, unit tests especially.
If you can't write a test to validate the behaviour that you know your application needs to exhibit, then you probably can't write the code to create that behaviour in the first place. Or, in a less binary sense, if you would write a test which isn't "right", you're probably just as likely to have written code that isn't "right".
At least in the case with the test, you write the test and the code, and when the test fails (or, doesn't fail when it should) you're tipped off to something being funky.
I'm sure you could end up writing a test that's bad in just the right way to end up doing more harm than good, but I do think that's the exception(heh).
We've definitely written lots of tests that felt like net negative, and I think that's part of what burned some devs out on testing. When I joined, the few tests we had were "read a huge JSON file, run it through everything, and assert seemingly random numbers match." Not random, but the logic was so complex that the only sane way to update the tests when code changed was to rerun and copy the new output. (I suppose this is pretty similar to approval testing, which I do find useful for code areas that shouldn't change frequently.)
Similar issue with integration tests mocking huge network requests. Either you assert the request body matches an expected one, and need to update that whenever the signature changes (fairly common). Or you ignore the body, but that feels much less useful of a test.
I agree unit tests are hard to mess up, which is why I mostly gravitate to them. And TDD is fun when I actually do it properly.
I hear you. When you're trying to write one big test that verifies the whole code flow or whatever, it can be HELL, especially if the code has been written in a way that makes it difficult to write a robust test.
God, big mocks are the WORST. It might not be applicable in your case, but I far prefer doing some setup and teardown so that I'm actually making the network request, against some test endpoint that I set up in the setup stage. That way you know the issues aren't cropping up due to some mocking nonsense going wrong.
Asserting that some arbitrary numbers match can be quite fragile, as I'm sure you've experienced. But if the code itsself had been written in such a way that you had an easier assertion to make, well, winner!
Its all easier said than done, of course, but your colleagues having given up on testing because they're bad at it is kinda disheartening I bet. How are you gonna get good at it if you don't do it! :D
I definitely deserve a lot of blame for designing my primary project in making hard to test. So, word to the wise (though it doesn't take a genius to figure this out), don't tell two fresh grads and a 1 YoE junior to "break the legacy app into microservices" with minimal oversight. If I did things again, I still think the only sane decision would be to cancel the project as soon as possible. x.x
I actually was using a mock webserver with the expected request/response, which sounds like what you're getting at. Still felt fiddly though and doesn't solve the huge mock data problem which is more an architecture design failing.
I've mostly gotten away from testing huge methods with a seemingly arbitrary numbers in favor of testing small methods with slightly less arbitrary numbers, which feels like a pretty big improvement.
True. :)
Hahahahaha I feel that re: just kill the project!
Ah I thought you were just mocking the response, as opposed to having some real webserver so you don't have to faff with mocking stuff. Sounds like you did what I would have :P
That does sound like a big improvement! Anything you can do to make your own job easier