>It's a TSA Test. There is no possible way you can determine that one test has the correct result and the other doesn't. The test that reads the value should write the value, then read it back. Do not rely on the data to be in any state before the test unless you write the value right there.
>
>>That's the idea - the unit test will setup the data the way I need. Say, I have a method in my class that based on the preference table values makes slightly different things. In order for me to test both preference settings, I need to create two tests and in these tests change these settings. I think I may also need to restore them back after I'm done, but that's not my concern at the moment.

Here is how I have this test setup right now:

private void PrepareCloseDrawersForTest(String cSalespoint, String cOperator, Boolean changePreferences = false)
      {
         String cSQL = @"IF NOT EXISTS (SELECT 1 FROM dbo.sale_hdr WHERE salespoint = @salespoint AND operator = @operator)
UPDATE top (10) dbo.sale_hdr SET closeout = 0 WHERE salespoint = @salespoint AND operator = @operator;
";
         
         if (changePreferences)
            cSQL = "UPDATE dbo.prefs_sl SET closedrwrs=3;" + cSQL;
         else
            cSQL = "UPDATE dbo.prefs_sl SET closedrwrs=2;" + cSQL;

         using (SqlCommand sqlCommand = new SqlCommand(cSQL, middlewareMain.database.sqlConnection))
         {
            sqlCommand.Parameters.Add("@salespoint", System.Data.SqlDbType.Char, 6).Value = cSalespoint;
            sqlCommand.Parameters.Add("@operator", System.Data.SqlDbType.Char, 6).Value = cOperator;
            sqlCommand.ExecuteNonQuery();
         }
      }

      [TestMethod]
      public void S_CloseDrawerNoClose1()
      {
         SalesUnitTest.isClassInitialized = false; // Need to re-initialize
         SalesUnitTest.ClassInit(null);
         PrepareCloseDrawersForTest("TICKET", "ADMIN");
         
         String input = @"<FUNC>CloseDrawer</FUNC><TCSALESPOINT>TICKET</TCSALESPOINT><TCOPERATOR>ADMIN</TCOPERATOR>
                  <TCDETAILS><STOCK_T1_S1>2</STOCK_T1_S1><STOCK_T1_E1>37</STOCK_T1_E1></TCDETAILS><tcNoClose>YES</tcNoClose>";
         String result = middlewareMain.Invoke(input);

         String expected = "<ERR>0</ERR><STATUSCODE>0</STATUSCODE><MSG>106 sales to close out</MSG>";
         Assert.IsTrue(String.Equals(expected, result, StringComparison.OrdinalIgnoreCase), result);
      }

      [TestMethod]
      public void S_CloseDrawerNoClose2()
      {
         SalesUnitTest.isClassInitialized = false; // Need to re-initialize
         SalesUnitTest.ClassInit(null);
         PrepareCloseDrawersForTest("TICKET", "ADMIN", true);

         String input = @"<FUNC>CloseDrawer</FUNC><TCSALESPOINT>TICKET</TCSALESPOINT><TCOPERATOR>ADMIN</TCOPERATOR>
                  <TCDETAILS><STOCK_T1_S1>2</STOCK_T1_S1><STOCK_T1_E1>37</STOCK_T1_E1></TCDETAILS><tcNoClose>YES</tcNoClose>";
         String result = middlewareMain.Invoke(input);

         String expected = "<ERR>0</ERR><STATUSCODE>0</STATUSCODE><MSG>497 sales to close out</MSG>";
         Assert.IsTrue(String.Equals(expected, result, StringComparison.OrdinalIgnoreCase), result);
      }

No close parameter means I am not performing the actual closeout but finding how many sales I need to close out.

I understand that these tests are data dependent. Right now 497 and 106 are the values I need. So, if right now these two tests return that information, I can tell that my procedure is doing what it is supposed to do. In the long run these numbers can change.

What you suggest for the above scenario?