this post was submitted on 21 Feb 2024
290 points (91.7% liked)

Work Reform

9964 readers
284 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:

Our Goals

founded 1 year ago
MODERATORS
 

i saw someone on twitter saying to "leverage your network" i'd sooner leverage a shotgun into my mouth jesus fucking christ

plus all this is meant to be done at a time when you're likely at your lowest confidence, most insecure, and most desperate.

just the idea that it's my job to sell myself to these sorts of business goons who ENJOY seeing people desperate and on edge is so sick. i have nothing to sell, i am not a commodity, i am a human being. and everything's ran thru some shitty AI now i'm sure. like the applications weren't demeaning enough.

can't we all just be assigned jobs by the government? it'd build social cohesion. like the hunger games. maybe you can opt out but I'd rather take my chances than answer these fucking personality tests or get so hopeless i'm actually applying for something with hours I hate with a miserable commute with a terrible wage which ALSO won't hire me

you are viewing a single comment's thread
view the rest of the comments
[–] pixxelkick@lemmy.world 1 points 8 months ago

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:

  1. 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.

  2. 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:

public class StudentService(IStudentRepository repo)
{

    public bool AnyGrade12()
    {
        var students = repo.GetStudents();
        return students.Any(s => s.Grade == 12);
    }
}

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:

public static class StudentService
{

    public static bool AnyGrade12(IEnumerable students)
    {
        return students.Any(s => s.Grade == 12);
    }
}

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.