Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
well, unit tests are there to ensure that code works as expected and it can handle any correct or incorrect data supplied to your methods. If the data has changed (e.g. set of supported data, set of unsupported data), this should be also reflected in the unittests by either amending existing test cases reflecting data evaluation changes or/and by adding new test cases guarding the new data processing rules.
-
I only code in unit tests for libraries as a kind of spec for how the libraries should be expected to behave when used
Can also be useful if you're coding something algorithmically complicated, cuz 100% you're going to get it wrong a few times before you get it right, and even if you get it right you may have missed some edge case
For all other things manual testing is faster and writing tests for it would be more work than writing the code itself -
@TeachMeCode I got obsesssedddd with test coverage. I loved getting it to 100% so much. It had to be 100% branching too 😋
I'm annoyingly a completionist though. Makes me feel good after. And I have the time
I didn't always do 100%... Some libraries you couldn't test the hookup code so it was like 99% but that's basically 100%
But still I don't even know it's just so satisfying. I'd only do this for libraries though. I published them and re-used them a lot, why not?
Also making sure they have no dependencies, lol
I purely do this for my own enjoyment 🤣 -
I am building an HTML parser in c++.
It's a non-trivial task that has a lot of iterative changes required. For example, first I got it to parse text nodes. Then, tags. Then, tags and attributes. Then, comments.
Each time I add something, I write unit tests that cover a reasonable amount of regular cases and a few edge cases that I decide I care about.
Each time I add something, it modifies the behavior of the state machine(s) and I need to validate that old behavior is still working. Now, I have the option of manually giving the program input each time I implement something, and by the time I have 500 features, I can spend one day coding and two weeks testing.
Or I could have been building unit tests throughout my development of the project. Now, I have a collection of tests which validate my code's behavior. Maybe if I change the APIs of my parser, the unit tests will need to be updated to work. But such is the way of writing and improving your code.
Now i am given a task to refactor some piece of Predicate code and then update the unit test so it can be compatible and work with new data
WHAT. Is the Fucking point of unit tests if you have to modify them to adapt to new code anyways???
Unit tests exist just so u can stroke ur sausage??? Just so u can give ur ego an orgasm to tell others "hey look at me how good code i wrote that even unit tests are passing!" ???
I always found unit tests sketchy. almost as if its useless and unnecessary. I still get why they are used (some other dev working on feature 2 might break my shit and unit test can save the day) but if thats the only reason then that doesnt seem like a strong enough reason for me
By now im talking about java!
No wonder i have never seen a single nextjs developer ever write a single unit test. Those people have evolved beyond unit testing just as the nextjs technology itself!
This is why nextjs is the future of web and the Big Daddy Dick King 👑 of technology!
rant