Ranter
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
Comments
-
I keep my unit tests as refactor resisting as possible. As less changes in tests is needed from main code changes as I could. Trying them being as black box testing as possible, without them being too much attached to implementing details.
They work as intended I guess most of the time. When they break, something really in main code goes broken.
If it would not for them, I would not have remembered the thing they pointed. Quite like them for good self control and ability to allow forgetting what happens in some second module. Tests will show me if some thing got broken -
@darkwind
Well, our tests will blow up every time logic changes, and that changes dynamically
And this refactor changed significant amount of how things are wired, basically deprecating significant amount of services (thus their mocks) and helpers (and their mocks), so I got rid of them in tests -
@mabbott94
I dont mind tests too much, they ate just annoying. I mind rewriting them becouse one dude and another does not do the cr in reasonable time so I cant merge the pr, than code waits enough that i need to do same work 2 times
Related Rants
2 weeks+ ago I made a PR into our codebase containing sample refactor that streamlined a significant portion of code. Also, I did refactor only on two handler packages (for MVC folks, that's Controller) as proof of concept, to figure out how convinient / logical the part would be for everyone.
We have rule of 2 approvals for merge (for 5 team members)
While writing refactor, it obviously blown up a lot of unit tests, but still coverage was fairly poor (that stuff was rushed, there was back than no time for unit tests). After my refactor I spent couple of days writing tests that hit fairly sweet (comparatively) coverage. (I managed to bump coverage from low 20s to high 80s, and have less code for tests)
I got first approve pretty much immidietely, other team member was on vacations, and 2 of them forgot.
We generally try to close PRs fairly quickly (usually same day kind of deal), but that one was just.. hanging in there. So I pinged everyone to re-check it to greenlight it but of course, loo and behold, merge conflicts arised. I ended up fixing actual logic (just some method signatures changed, not a big deal) and ran the units.
So, one of that handlers got quite a few of edits, and guess who is pretty much rewriting unit tests for second time now...
Dude, sometimes I question why tf I even bother with these tests... Feels like sabotaging my productivity, especially with bullshit like that
rant
unit test