On a serious note, I love cooking and washing and cleaning. I’m not staring at a screen and the objective is clear.
I’m not contemplating whether this is worth my time or stressed about other things. Although, I don’t cook for many people so I guess my outlook would be different in those cases.
Not testing is crazy. Once you realize you can actually refactor without ever having the fear you’ve broken something, there’s actually opportunity to make rapid improvments in structure and performance. Taking 2 minutes to write the test can save your hours of debugging. Unless you’re building a throwaway prototype, not unit testing is always the wrong choice.
Basically: The game is Cataclysm: Dark Days Ahead. For those not aware of how the game works, it operates in turns, with every character and monster getting 100 turns to perform actions before the other creatures in the game get theirs. Each action takes a set amount of turns, and you can take actions until your 100 turns are used. So walking a tile might take 80 turns, and running that same tile 40, giving you an extra tile before the other creatures get to go.
What happened here is, a commit changed how limb breaks affect turns, but didn’t put a maximum cap. Meaning that players would spend 0 turns moving. If you don’t spend any turns, other things in the game never get theirs. In other words, time stops for everyone but you.
One rule of thumb I’ve heard and follow is that every time you encounter a bug, you write a unit test that would catch it. I find that does a pretty good job of getting high code coverage, though maybe that’s cause my code is naturally buggy 😅.
Here’s my take. In order to be able to write meaningful unit tests the code should be structured in a certain way, with very modular, decoupled units, dependency injection, favoring composition and polymorphism over inheritance and so on.
If you manage to write your code this way it will be an objective advantage that will benefit the project even if you don’t write a single unit test. But it does make unit tests much easier to write, so presumably you’ll end up with more tests than otherwise.
IMO teams should prioritize this way of writing code over high test coverage of non-modular code. Unit tests for deeply-coupled code are a nightmare to write and maintain and are usually mostly meaningless too.
You don’t suddenly find out that your peeler is several versions behind
And then proceed to spend 17 hours trying to get it to peel just the way the invetors wanted it to, which is different from the other 987654321 peelers around.
After 20 years in the field, I hate love despise like 'm ok with technology
I thought you could put curly brackets on a new line in js? Although I know when returning an object it has to be on the same line… fuck JavaScript man
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.