Show HN: A C# library to help you enforce a Given-When-Then structured Unit test

to be honest, I'd much prefer this

   [TestMethod]
   public void ShouldBeAbleToTestActions()    
   { 
     var dwarfs = new List<string>() { "Sneezy", "Bashful", "Sleepy", "Happy", "Grumpy", "Doc", "Dopey" };
     Action<List<string>> DoDarkMagic = (creatures) => { creatures.RemoveAt(0); }
     DoDarkMagic(dwarfs)
     Should("have less dwarfs", () => { dwarfs.Count.Should().Be(6); });
     Should("missing Sneezy", () => { dwarfs.Should().NotContain("Sneezy"); });
   };

    Action<List<string>> DoDarkMagic = (creatures) => { creatures.RemoveAt(0); }
    DoDarkMagic(dwarfs)

    // Do Dark Magic
    dwarfs.RemoveAt(0);

This seems a bit too fluent, but most Testing APIs for Java and C# seem to be heavily into fluent styles (everyone else seems to avoid them).

I'm designing an internal library myself that does the same thing using Kotlin's EDSL support (you can specify the "this" type of a function) and splits test logic up into required, act, and provided blocks. E.g.

   required {
     // will be made true for test
     check(something) 
   }
   act {
     // the act under test 
     click(someButton)
   }
   provided {
     // will be verified for test 
     check(something)
   }

The interesting thing here is that the polarity of the required and provided blocks can be flipped (check the required is true, and if it is make the provided true) to do fakes/mocks. Well, it is still something I'm working on.

My teams use a snippet that expands to the following

    [Fact(Skip = "Generated With Snippet")]
    public async Task MyTestMethodAsync()
    {
      //Arrange


      //Act


      //Assert
      throw new NotImplementedException();
    }

If that results in hard to read unittests I suspect that your library would too, as it is a matter discipline. If we assume that we use your terms, "Given, When, Then" in place of "Arrange, Act, Assert" - can you give an argument that would favour your solution with the syntactic overhead of putting it all in lambdas?

The examples look like a lot more work. The ingredients and naming those into tuple variables, having to return the tuple type itself, three lambdas in there.

What benefit do these abstractions give me over simply coding an Arrange/Act/Assert?

To be frank, I find it a bit overengineered.

Besides, it's been a while since I did any C# programming, but does it really "enforce" the structure, or only encourage it?

I mean, what's to stop people from going eg.

    int ingredient1 = 1;
    int ingredient2 = 2;

    Given(() =>
    {
        Func<int, int, int> noodleMaker = (x, y) => x + y;
    // ...

Putting some declarations outside of the "given" section?

If it's just a matter of good will and adhering to the convention, then we're kind of back to square one - if you're a good scout, you could have stuck to the convention even without the extra library.

Unless there's something I'm missing

Thank you guys for your comments. I totally agree with most of you, when the tests are short and simple, when everyone on your team follows good practice, this library is probably an overkill.

But when your system is a bit more complex or a legacy, your unit tests are complex, your team is not that mature, not everyone follows good practice, comments does not match with reality or even crunch multiple scenarios into a single tests, asking them to re-write unit test may sounds rude...(guess I might sounds more like complaining now...), but anyway, that is kinda how all of a sudden this idea came to me the other day while I was writing my own unit tests.

My ideas is if my team can adopt this, at least this can help us improve unit test qualities and readability. Then maybe once we become a more mature team, we can ditch the 'crutches'.

Looks like a similar concept to https://github.com/machine/machine.specifications which I used many years ago to try and achieve BDD style unit testing.

One point to note from your introduction was the following statement: I often find unit tests are hard to read, and especially harder to quickly identify what are the important pieces, or even what the test is testing about

Have you considered pairing with others in your team or using group code reviews to see if there is a style or understanding gap? This may be far more effective than trying to get people to use a novel unit testing framework with little or no real longevity.