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?
36 Replies
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!