I did something similar but better (just for norm data access instead of ef) and I described it here: dev.to/vbilopav/net-identity-with-... (see unit tests chapter)
It is better because every single test runs under a new transaction that is rolled back when a test is finished which ensures total test isolation. Anything you do in one test is invisible in other and it is clear up (rolled back) when a test is finished. Otherwise, I'd have to run those tests in serial (one after another) which I don't like.
That is just to demonstrate my micro orm but I have the same solution for PostgreSQL database tests with transactions that use EF done for a client.
What I described in this post is creating a completely new database for each test (by cloning the template). So it creates a database -> run test -> drop database over and over for each test. Also, there is no problem in running these tests in parallel.
So because of this, I wouldn't say that neither solution is better than the other. Both are isolated per test, one with a database per test, the other with transaction per test.
But, thanks for showing the Norm. The name is quite funny to me, it reminded me NotORM from the PHP world I used some time ago.
Performance-wise new database will be slower. The first step is creating a new template database. Cloning that template database for each test is fast and runs in parallel. But you made me curious, I'll try to measure the impact.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I did something similar but better (just for norm data access instead of ef) and I described it here: dev.to/vbilopav/net-identity-with-... (see unit tests chapter)
It is better because every single test runs under a new transaction that is rolled back when a test is finished which ensures total test isolation. Anything you do in one test is invisible in other and it is clear up (rolled back) when a test is finished. Otherwise, I'd have to run those tests in serial (one after another) which I don't like.
That is just to demonstrate my micro orm but I have the same solution for PostgreSQL database tests with transactions that use EF done for a client.
What I described in this post is creating a completely new database for each test (by cloning the template). So it creates a database -> run test -> drop database over and over for each test. Also, there is no problem in running these tests in parallel.
So because of this, I wouldn't say that neither solution is better than the other. Both are isolated per test, one with a database per test, the other with transaction per test.
But, thanks for showing the Norm. The name is quite funny to me, it reminded me NotORM from the PHP world I used some time ago.
That's interesting, new database for each test. I never thought of it. I wonder how it performs vs transaction per test. Thanks
Performance-wise new database will be slower. The first step is creating a new template database. Cloning that template database for each test is fast and runs in parallel. But you made me curious, I'll try to measure the impact.