title: Unit Testing: Self-contained tests vs code duplication (DRY)
body: <p>I'm making my first steps with unit testing and am unsure about two paradigms which seem to contradict themselves on unit tests, which is:</p>
  
  <ul>
  <li>Every single unit test should be self-contained and not depend on others.</li>
  <li>Don't repeat yourself.</li>
  </ul>
  
  <p>To be more concrete, I've got an importer which I want to test. The Importer has a "Import" function, taking raw data (e.g. out of a CSV) and returning an object of a certain kind which also will be stored into a database through ORM (LinqToSQL in this case).</p>
  
  <p>Now I want to test several things, e.g. that the returned object returned is not null, that it's mandatory fields are not null or empty and that it's attributes got the correct values. I wrote 3 unit tests for this. Should each test import and get the job or does this belong into a general setup-logic? On the other hand, <a href="http://jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html" rel="noreferrer">believing this blog post</a>, the latter would be a bad idea as far as my understanding goes. Also, wouldn't this violate the self-containment?</p>
  
  <p>My class looks like this:</p>
  
  <pre><code>[TestFixture]
  public class ImportJob
  {
      private TransactionScope scope;
      private CsvImporter csvImporter;
  
      private readonly string[] row = { "" };
  
      public ImportJob()
      {
          CsvReader reader = new CsvReader(new StreamReader(
                      @"C:\SomePath\unit_test.csv", Encoding.Default),
                      false, ';');
          reader.MissingFieldAction = MissingFieldAction.ReplaceByEmpty;
  
          int fieldCount = reader.FieldCount;
          row = new string[fieldCount];
  
          reader.ReadNextRecord();
          reader.CopyCurrentRecordTo(row);
      }
  
      [SetUp]
      public void SetUp()
      {
          scope = new TransactionScope();
          csvImporter = new CsvImporter();
      }
  
      [TearDown]
      public void TearDown()
      {
          scope.Dispose();
      }
  
      [Test]
      public void ImportJob_IsNotNull()
      {
          Job j = csvImporter.ImportJob(row);
  
          Assert.IsNotNull(j);
      }
  
      [Test]
      public void ImportJob_MandatoryFields_AreNotNull()
      {
          Job j = csvImporter.ImportJob(row);
  
          Assert.IsNotNull(j.Customer);
          Assert.IsNotNull(j.DateCreated);
          Assert.IsNotNull(j.OrderNo);
      }
  
      [Test]
      public void ImportJob_MandatoryFields_AreValid()
      {
          Job j = csvImporter.ImportJob(row);
          Customer c = csvImporter.GetCustomer("01-01234567");
  
          Assert.AreEqual(j.Customer, c);
          Assert.That(j.DateCreated.Date == DateTime.Now.Date);
          Assert.That(j.OrderNo == row[(int)Csv.RechNmrPruef]);
  
      }
  
      // etc. ...
  }
  </code></pre>
  
  <p>As can be seen, I'm doing the line <code>Job j = csvImporter.ImportJob(row);
  </code> in every unit test, as they should be self-contained. But this does violate the DRY principle and may possibly cause performance issues some day.</p>
  
  <p>What's the best practice in this case?</p>