4 ms·

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

24 points by cobrakailab 5y ago

I always strive to write better, clean and readable code. But 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. So I came up with this lightweight library to help enforce unit tests with a Given-When-Then structure. I hope you find this useful. Any feedback are welcome. https://github.com/cobrakai-lab/Cobrakai.GWTUnit

hvidgaard 5y ago
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?
- moogly 5y ago
  Ah, my pet peeve. I also prefer AAA tests, but I can't stand it when people leave those comments in as some kind of region markers. IMO, they're useful when teaching AAA tests, but it seems, in my experience, most developers actually have those comments in every. single. test. That's some hardcore cargo culting. I just use a blank line to separate the different stages, and if you have problems making that readable, you probably need to refactor the Arrange or Assert parts to use some helper methods. I realize I'm probably overreacting, but I feel the anger rising whenever I see this in the wild (and have to suppress it).
  - hvidgaard 5y ago
    It's to ensure that it's actually adhered to. Unfortunately experience have shown that it's unreasonable to expect all developers to remember this on their own accord. I generally also advise the leads to make sure there is a reasonable limit to the length of a test method. As you say if it's too long it probably needs some work before it's allowed in the main branch.
  - pc86 5y ago
    You can always just overwrite the comments with the first line of code. If this actually makes you angry and you're not just hyperbolizing for literary flair you need to see a therapist.
    - moogly 5y ago
      > You can always just overwrite the comments with the first line of code. I of course mean leaving the comments in the final test. I don't care about the comments in the actual snippet.
- lozenge 5y ago
  "given a csv file when a column is missing then it is named in the thrown exception" Vs "arrange a csv with a missing column act read it assert the exception contains the missing column name"
  - hvidgaard 5y ago
    I already covered that. > If we assume that we use your terms, "Given, When, Then" in place of "Arrange, Act, Assert"
fexelein 5y ago
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?
- SideburnsOfDoom 5y ago
  > What benefit do these abstractions give me Tests in larger c# projects are often a mess. People then turn to BDD or frameworks like to this to try to impose order. Sometimes they produce better tests the second time around, but more often the additional overhead of the framework just means that "now you have 2 problems". Probably no benefit, IMHO. Work on your tests, but avoid "high concept" frameworks.
keithnz 5y ago
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"); }); };
- SideburnsOfDoom 5y ago
  Agreed, simpler is better. To be even simpler, In this example, these two lines can be just one: Action<List<string>> DoDarkMagic = (creatures) => { creatures.RemoveAt(0); } DoDarkMagic(dwarfs) There is no point in putting the action in a variable, only to invoke it on the next line. This is a meandering way of expressing: // Do Dark Magic dwarfs.RemoveAt(0); Extract a private method if you're keen on keeping the name.
  - keithnz 5y ago
    it was just an example on the authors page, he explains that in reality you'd actually have some real thing you'd be testing
    - SideburnsOfDoom 5y ago
      yes, it's an example of how these frameworks encourage accidental complexity.
seanmcdirmid 5y ago
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.
- weitzj 5y ago
  Sounds like the Testing Robots Pattern which I first heard from Jake Wharton. Looks really nice https://jakewharton.com/testing-robots/ https://jakewharton.com/testing-robots/
V-2 5y ago
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
cobrakailab 5y ago
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'.
random_coder_nz 5y ago
Looks like a similar concept to https://github.com/machine/machine.specifications 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.

24 points by cobrakailab 5y ago

hvidgaard 5y ago

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?

moogly 5y ago
Ah, my pet peeve. I also prefer AAA tests, but I can't stand it when people leave those comments in as some kind of region markers. IMO, they're useful when teaching AAA tests, but it seems, in my experience, most developers actually have those comments in every. single. test. That's some hardcore cargo culting. I just use a blank line to separate the different stages, and if you have problems making that readable, you probably need to refactor the Arrange or Assert parts to use some helper methods. I realize I'm probably overreacting, but I feel the anger rising whenever I see this in the wild (and have to suppress it).
- hvidgaard 5y ago
  It's to ensure that it's actually adhered to. Unfortunately experience have shown that it's unreasonable to expect all developers to remember this on their own accord. I generally also advise the leads to make sure there is a reasonable limit to the length of a test method. As you say if it's too long it probably needs some work before it's allowed in the main branch.
- pc86 5y ago
  You can always just overwrite the comments with the first line of code. If this actually makes you angry and you're not just hyperbolizing for literary flair you need to see a therapist.
  - moogly 5y ago
    > You can always just overwrite the comments with the first line of code. I of course mean leaving the comments in the final test. I don't care about the comments in the actual snippet.
lozenge 5y ago
"given a csv file when a column is missing then it is named in the thrown exception" Vs "arrange a csv with a missing column act read it assert the exception contains the missing column name"
- hvidgaard 5y ago
  I already covered that. > If we assume that we use your terms, "Given, When, Then" in place of "Arrange, Act, Assert"

fexelein 5y ago

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?

SideburnsOfDoom 5y ago
> What benefit do these abstractions give me Tests in larger c# projects are often a mess. People then turn to BDD or frameworks like to this to try to impose order. Sometimes they produce better tests the second time around, but more often the additional overhead of the framework just means that "now you have 2 problems". Probably no benefit, IMHO. Work on your tests, but avoid "high concept" frameworks.

keithnz 5y ago

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"); }); };

SideburnsOfDoom 5y ago
Agreed, simpler is better. To be even simpler, In this example, these two lines can be just one: Action<List<string>> DoDarkMagic = (creatures) => { creatures.RemoveAt(0); } DoDarkMagic(dwarfs) There is no point in putting the action in a variable, only to invoke it on the next line. This is a meandering way of expressing: // Do Dark Magic dwarfs.RemoveAt(0); Extract a private method if you're keen on keeping the name.
- keithnz 5y ago
  it was just an example on the authors page, he explains that in reality you'd actually have some real thing you'd be testing
  - SideburnsOfDoom 5y ago
    yes, it's an example of how these frameworks encourage accidental complexity.

seanmcdirmid 5y ago

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.

weitzj 5y ago
Sounds like the Testing Robots Pattern which I first heard from Jake Wharton. Looks really nice https://jakewharton.com/testing-robots/ https://jakewharton.com/testing-robots/

V-2 5y ago

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

cobrakailab 5y ago

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

random_coder_nz 5y ago

Looks like a similar concept to https://github.com/machine/machine.specifications 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.