Live data from Hacker News

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

news.ycombinator.com

11–19 of 19 posts

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

#11
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 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

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

#12
post #7

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 ar…

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, y…

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.

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

#13
post #8

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 ar…

"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"

I already covered that.

> If we assume that we use your terms, "Given, When, Then" in place of "Arrange, Act, Assert"

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

#14
post #2

to be honest, I'd much prefer this [TestMethod] public void ShouldBeAbleToTestActions() { var dwarfs = new List () { "Sneezy", "Bashful", "Sleepy", "Happy", "Grumpy", "Doc", "Dopey" }; Action > DoDarkMagic = (creatures) => { creatures.RemoveAt(0); } DoDarkMagic(dwarfs) Should("have less dwarfs", () => { dwarfs.Count.Should().Be(6); }); Should("missing Sneezy", () => { dwarfs.Should().NotContain("Sneezy"); }); };

Agreed, simpler is better. To be even simpler, In this example, these two lines can be just one: Action > 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.

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

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

#15
post #7

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 ar…

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, y…

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.

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

#16
post #14

Earlier quoted context omitted.

Agreed, simpler is better. To be even simpler, In this example, these two lines can be just one: Action > 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.

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

yes, it's an example of how these frameworks encourage accidental complexity.

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

#17
post #15
post #7

Earlier quoted context omitted.

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, y…

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.

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

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

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

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

#19
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.

Post reply on HN