this post was submitted on 21 Feb 2024
289 points (91.6% liked)
Work Reform
9994 readers
130 users here now
A place to discuss positive changes that can make work more equitable, and to vent about current practices. We are NOT against work; we just want the fruits of our labor to be recognized better.
Our Philosophies:
- All workers must be paid a living wage for their labor.
- Income inequality is the main cause of lower living standards.
- Workers must join together and fight back for what is rightfully theirs.
- We must not be divided and conquered. Workers gain the most when they focus on unifying issues.
Our Goals
- Higher wages for underpaid workers.
- Better worker representation, including but not limited to unions.
- Better and fewer working hours.
- Stimulating a massive wave of worker organizing in the United States and beyond.
- Organizing and supporting political causes and campaigns that put workers first.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I despise the current paradigm of mock'ing everything, abstracting everything, and unit testing 100% cide coverage for no logical reason.
Instead I only unit test the following:
Any code I truly want to unit test, because it does something that is iffy on if it works or not, I break out into atomic logic that can very easily unit test.
Code coverage is a business requirement and we already have 100% coverage from integration tests, then I'll start worrying about unit testing the shit out of stuff.
In other words if you waste time on mindless unit tests to assert that 1+1=2 when you dont have 100% coverage on your integration tests yet, you are wasting time.
In terms of atomic code, consider this example:
This would be very normal as a pattern to see, but I hate it because to test it, now I need to mock a stubbed in IStudentRepository.
Consider this instead:
Now this is what I consider atomic logic. The rule of thumb is, if the class has no dependencies or all it's dependencies are atomic, it too is atomic.
Generally it becomes clear all the atomic logic can just be declared as static classes pain-free, and there's no need to abstract it. It's trivial to unit test, and you don't have to mock anything.
Any remaining non-atomic code should end up as anything you simply must integration test against (3rd party api calls, database queries, that sort of stuff)
You'll also often find many of your atomic functions naturally and smoothly slot into becoming just extension functions.
This approach goes very much against the grain of every dotnet team I've worked with, but once I started demoing how it works and they saw how my unit tests became much less convoluted while still hitting ~90% code coverage, some folks started to get on board with the paradigm.