Databases
StackOverflow2013
Postsdbo
POMSTest Unit tests (VS 2012) vs. SQL Server, intermittent Primary Key collisions
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POMSTest Unit tests (VS 2012) vs. SQL Server, intermittent Primary Key collisions
    primarykey
    data
    text
    <p>I'm dealing with a very strange problem. Initially, I thought this was a problem with cleaning up test data... but after completely refactoring my test data cleanup code and still seeing the exact same behavior... I'm at a loss.</p> <p>I have 245 unit test methods in various classes. Each class has its own unique test data, and I initialize those objects, and then in each test method that data is usually inserted into the database and then manipulated with the tests. Each test class has a ClassCleanup method that cleans out all of the test data from the database, and that ClassCleanup is also run on TestInitialize, to ensure everything is cleaned up before any other test method is run.</p> <p>When I "Run All" using VS 2012 Test Explorer, 22 tests fail. They all fail with some variation of Primary Key constraint violations. Meaning, when they are initializing data for these tests, the data was not cleaned up from a previous test method in that class. If I re-run all tests, I get the same tests failing every time. This is fairly reproducible. No matter how many times I run all tests. These same 27 tests fail with primary key violations.</p> <p>However, the weird thing is that if I re-run ONLY those failed tests, only 9 tests fail. This is ALSO reproducible, meaning, no matter how many times I run only these 27 previously failing tests, 14 will fail, and the rest will pass. This continues as I run only failed tests, until I get to a point where none of the tests fail. It should also be noted that if I run each test class individually, everything passes.</p> <p>I know how this looks. </p> <p>"You obviously are not cleaning up your test data." If that were the case, then I should see the same tests fail on every run, no matter what. Those 27 tests should fail EVERY run, not just when I run everything else.</p> <p>"You must not have unique primary keys between classes and things aren't being cleaned up." See above. Even IF I had primary keys repeated in my classes (which I don't, because I have personally triple-checked the uniqueness of the primary keys on test data within the various classes), since these tests are not run concurrently on separate threads (which has been verified by logging the ThreadId), the cleanup code for any given test would clean out the duplicated data, regardless.</p> <p>"You must not be using connection pooling." No, actually I am. And I've verified using SQL Profiler that the requests are definitely pooled. Also, because these tests are not running in parallel, there is only ever the one connection thread.</p> <p>"You shouldn't use connection pooling." Well, yes, I should, since the underlying codebase supports various web projects, but for the sake of argument I tried running all the tests with connection pooling disabled (using Pooling=false in the connection string) and I get the exact same results. No change in behavior, whatsoever.</p> <p>"There must be something wrong with your local environment." I get the same results running these tests on other colleagues' dev boxes (which incidentally use SQL 2012), as well. This is not unique to my environment, or even my version of SQL Server.</p> <p>"You should try running mstest from the command line." Already did that. Same results.</p> <p>If anyone has encountered something like this, please let me know. I know there must be something simple I'm missing, as that's usually the case with these kinds of problems, but I've covered as many bases as I possibly can in trying to sort this out.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USFinster
    1. USFinster
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POMSTest Unit tests (VS 2012) vs. SQL Server, intermittent Primary Key collisions
      1. USFinster
      1. VTBountyStart
    2. VO
      singulars
      1. POMSTest Unit tests (VS 2012) vs. SQL Server, intermittent Primary Key collisions
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POMSTest Unit tests (VS 2012) vs. SQL Server, intermittent Primary Key collisions
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI had a similar problem but I found out that it was my wrong test implementation that caused it (of course nothing to do with your case). You problem is very wierd so it's logical for everyone to ask the questions you mentioned. Please post a sample of one of your test classes. Especially the way you roll back your database changes. Otherwise you are unlikely to get a good answer.
      singulars
      1. POMSTest Unit tests (VS 2012) vs. SQL Server, intermittent Primary Key collisions
      1. USSchaliasos
    2. COYou mentioned that they succeed individually. What is the minimum number of test cases you can run and have one fail? Can you reduce it down to two cases? Have you ran profiler to capture the entire run when it produces an error?
      singulars
      1. POMSTest Unit tests (VS 2012) vs. SQL Server, intermittent Primary Key collisions
      1. USStrayCatDBA
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload