Unit-testing framework (.Net)

[fredjeronimo]

We use a single one in Prompt:

• NUnit - Adopt

[adrianbanks]

• xUnit
• Fixie

Probably need some libraries for Javascript unit testing as well.

[ChrisHurley]

I might up that to NUnit 3 - Adopt. Is NUnit 2 Endure or Retire? (It has breaking changes.)

JavaScript and, more also specifically, React testing is definitely an area we haven't pinned down.

[nyctef]

We've been using jest for general js testing, which appears to work just fine.

We've successfully written some React component tests with jest and enzyme but haven't found them particularly useful beyond a proof of concept

[nyctef]

I might up that to NUnit 3 - Adopt. Is NUnit 2 Endure or Retire? (It has breaking changes.)

+1 to splitting these out. I think Endure is probably appropriate for NUnit 2 - as far as I know there's nothing wrong with using 2, but you might as well use 3 for any new development. AFAIK CompareEngine migrated to 3 for the new parallel execution features, but apart from that it'd happily been using 2 for many years.

[ChrisLambrou]

Does Pester count as a testing framework for .NET? It's for PowerShell! 😁

[fffej]

For the C# stuff, it feels like we're pretty close to consensus?

Adopt:

• NUnit 3

Retire

• NUnit 2 (simplifies build/test system - I could be argued down to Endure 😄 )

For xUnit/Fixie - what benefit could these packages give us? Is there anything significant enough to warrant putting them in Explore? From a quick look, they looked different (maybe more customisation)? I'm worried about the knock-on impacts (e.g. it'd need to work with TeamCity test runners, the build system, NCrunch and more). Is this one where we should just keep it simple? What'd you think @adrianbanks?

[nyctef]

• NUnit 2 (simplifies build/test system - I could be argued down to Endure 😄 )

I don't think actively retiring NUnit 2 simplifies our build/test system - we tend to encourage people to manage their own testing dependencies for exactly this kind of reason, so I think Endure is probably most appropriate.

From a quick look, they looked different (maybe more customisation)? I'm worried about the knock-on impacts (e.g. it'd need to work with TeamCity test runners, the build system, NCrunch and more)

As far as I know xUnit tends to be supported everywhere NUnit is (eg in NCrunch/R#/teamcity/etc at least) - I don't know of any really compelling reason to switch away from NUnit though.

I hadn't heard of Fixie until this issue - looks like it can output nunit-style xml reports, so it'll at least work with the build system. Other tools might be a bit trickier, though.

[nyctef]

Just remembered we've been using some custom assertion libraries like FluentAssertions and Shouldly on top of NUnit - these should probably go into the radar around here as well. Both of them improve code readability and error usefulness over the default NUnit assertions.

• FluentAssertions: has a wider variety of assertions you can use (including ShouldBeEquivalentTo() for comparing entire object graphs, which is very useful)
• Shouldly: Looks like fewer available assertions, but does some magic where it inspects the stack trace to generate useful assertion messages like contestant.Points should be 1337 but was 0 by default.

Personally I like FluentAssertions but don't have any experience with Shouldly so I can't say if one is definitely better than the other. I think both of them are a good idea in general, though.

[adrianbanks]

@fffej I only mentioned xUnit and Fixie as they were testing libraries we could also choose. I've used them a bit in my own things are they are more flexible than NUnit, but I don't think we should include them unless they are already in use within Redgate.

[fffej]

Sounds like we've got consensus on

Adopt

• NUnit 3 (the default choice for new things)

Endure

• NUnit 2 (doesn't cause us any problems, no benefits in upgrading in terms of simplifying).

Does anyone fancy making a PR on this and I'll merge it? (I'm trying to avoid being always me that creates PR's 😄)

[allymparker]

@Greg-Smulko Weren't you guys using a BDD style test framework?

[Greg-Smulko]

@allymparker, not really.
We use NUnit3 with a test names convention that reads as: RouterShould.GetTheCorrectViewModelForAValidLocation(), which is represented in code as:

    [TestFixture]
    public class RouterShould
    {
        [Test]
        public void GetTheCorrectViewModelForAValidLocation() { }
        [Test]
        public void GetTheCorrectViewModelWhenMultipleRoutesExist() { }
    }