How to structure unit tests [Answered]

This is more of a preference question than anything but how do you usually structure tests? I'm... not very good at writing tests and I haven't done it a lot, so I don't have that much experience. Do you typically create a separate test class for every type you want to test with methods within to tests specific functionalities of the class?

entirely depends on the context

just try to have meaningful tests

having 100% test coverage is not the goal

the goal is to have meaningful tests that will notify you in specific situations

if you unit test methods in ThatService.cs I'd create ThatServiceTests.cs

so, yeh

you can also follow/mimic your project structure in your tests - Data.csproj/Data.Tests.csproj then classes to follow whichever class you test

in short yes on your last question 🙂

There are many testing philosophies. I'm a strong proponent of: if you can avoid unit tests and write functional tests instead, do so

Not every codebase can do this, of course

what is a functional test? like end to end ones?

Mostly.

For example, in the compiler, we don't test individual lowering passes

yeah, that feels like best way to test stuff

We test the resulting IL

And we test observable results from our public APIs

unit test on the other hand give quick feedback when you're code gets built by the pipeline

your*

Right, that's one reason to use unit tests if you need to

For Roslyn, functional tests are more than fast enough for that feedback loop

do you use 3rd party libs for this? like specflow?

No

Not beyond Xunit, anyway

Hmm, alright

I think I'll like group things loosely by what they do then

If you're specifically talking about nanopass, Thinker, I'd suggest functional tests 🙂

How would that work?

From what you described it sounds more like "try it and see and debug if it doesn't work as expected" over testing specific parts of the app.

I thought you were an nunit guy

I’ve used specflow at times, but you definitely need to justify the need imho

I meant unit tests and not any kind of other tests

so, our friend 333fred, suggested functional tests are better than unit test so we kind of diverged, with regards to unit test what you assumed in your original question (last question specifically) is the way to go imho.

I am

But the compiler uses x

Yep

Use your public API to create input, and then test that the output is what you expect

it def depends on your general app, integration tests are a vital part of a webapi

but a compiler doesnt necessarily care about them

we run a full suite of tests against a live db on every workflow run

How do you run tests against a live DB?

Anyway I think I'll go with unit tests combined with some functional tests

I'll use a test-but-actual db, it gets spun up for the test

sounds expensive

What is the cost of a bug in production?

like a non trivial show stopper

I've never been in production so idk, but probably a lot

I tell my teams that a basic medium quality production bug costs the company about 5k

that was some back of the napkin math

but spinning up a cloud database, inserting some data, running some tests, and destroying the cloud database is only a few minutes

Minutes? wow

the most extreme case I've seen is 20 minutes

we have scripted data for tests, so deploy the database resource, deploy the scripts, run the tests, verify the tests, etc.

We connect to a cloud database from our runner

You have a custom test runner?

Yee i wrote a custom fixture

It xunit tho

So it just just a custom xunit fxiture

Every test gets a totally new database

Well, sorta, the data is cleared and reseeded per test

I keep the data for a test run

Even if the test inserts data?

it all gets wiped at the end

Ohh ya

We wipe them reinsert

✅ This post has been marked as answered!