title: Expensive maintenance with automated test data
body: <p>At my company, we have a growing set of integration test using JUnit in a Java Web application. Each test uses some specific external XMLs files to populate the database with the needed data to the test.
  The problem is:</p>
  
  <ol>
  <li>When there is a change in the model, we take a long time to correct all XML files (we have hundreds of XML files, a lot of them with redundancy).</li>
  <li>The complexity of creating an XML file manually discourages the programmer to explore different scenarios.</li>
  <li>We don't have a link between the test data and the test (e.g. At the test I don't know the 'name' of the User inserted by the XML). We could hard code the information we need, but it would also increase the maintenance time to keep both XML and hard coded data synchronized.</li>
  </ol>
  
  <p>Facing this problem, I started thinking in using the own system CRUD to generate test data for each test. At the beginning of each test I would run some methods to persist the desired data for the test.
  In my vision, it would resolve all the 3 problems since:</p>
  
  <ol>
  <li>Changes to the model require changing the CRUD anyway, so it would take no longer to correct the test data.</li>
  <li>It would be easier to build, test data because we would not worry about thing like matching id and foreign key of the entity manually.</li>
  <li>I would have all the important data in the variables with the sync guaranteed by the IDE.</li>
  </ol>
  
  <p>but, for me, it lacks experience and knowledge to start this approach.
  The question is:
  Is this solution effective? Does this approach cause other problems? Where I can find this approach in the literature? Is there a better solution to the listed problems?</p>