Loading ...
Sorry, an error occurred while loading the content.

Re: [junit] @BeforeClass method for DBUnit Dataset creation

Expand Messages
  • Mike Forsberg
    I would advise against that unless you were following the following guide lines.... - No test method (or called method) manipulates the data base. - The order
    Message 1 of 9 , Jul 1, 2010
    • 0 Attachment
      I would advise against that unless you were following the following guide
      lines....
      - No test method (or called method) manipulates the data base.
      - The order of the test methods do not cause conflicts with each other with
      required data being there.

      Some things I'd try before doing the @BeforeClass
      - Only populate the data you need for a given set of tests. (Don't populate
      the _whole_ database.)
      - Which of the DBUnit population features are you using... I think there is
      one that will revert to a known state, without the delete and insert. This
      may save some time.
      - Try to use a non-commitable transaction for testing. After all, one
      shouldn't need to test the commit functionality. If that breaks more than
      just you will have problems.

      Hope I helped,

      Big Mike


      On Wed, Jun 30, 2010 at 8:32 PM, hdave321321 <hdave321321@...> wrote:

      >
      >
      > My DAO integration tests are taking a long time to run. I am using Spring
      > Test which automatically does a transaction rollback after each test method.
      > However, I am also using DBUnit to load the exact same dataset before each
      > test method via the @BeforeTransaction annotation.
      >
      > It has occured to me that I could save a lot of time if I load the DBUnit
      > test data once per test class instead of once per test method.
      >
      > I've not used the @BeforeClass and @AfterClass methods before, but
      > apparently they require the annotated method to be static and this is
      > interfering with my normal use of Spring dependency injection that provides
      > an application context, data source, and other things I need to load the
      > correct data set.
      >
      > Anyone experience this before? What's a good way to address this problem?
      >
      >
      >


      [Non-text portions of this message have been removed]
    • hdave321321
      Thanks for the help. In my case, Spring Test does an automatic transaction rollback after every test method, so there are no dependencies between tests -- so
      Message 2 of 9 , Jul 1, 2010
      • 0 Attachment
        Thanks for the help. In my case, Spring Test does an automatic transaction rollback after every test method, so there are no dependencies between tests -- so thats not a problem. Because of the rollback, it is also the case that they order of the test runs also doesn't matter. The database is reset to a "known" state after each test method by the transactional rollback.

        I'd just like to load the data once rather than 50 times. But the @BeforeClass requirement to be a static method makes it impossible to use. Is there any trigger that can run after a class is initialized by Spring and before any test method is executed?

        --- In junit@yahoogroups.com, Mike Forsberg <bigmike.f@...> wrote:
        >
        > I would advise against that unless you were following the following guide
        > lines....
        > - No test method (or called method) manipulates the data base.
        > - The order of the test methods do not cause conflicts with each other with
        > required data being there.
        >
        > Some things I'd try before doing the @BeforeClass
        > - Only populate the data you need for a given set of tests. (Don't populate
        > the _whole_ database.)
        > - Which of the DBUnit population features are you using... I think there is
        > one that will revert to a known state, without the delete and insert. This
        > may save some time.
        > - Try to use a non-commitable transaction for testing. After all, one
        > shouldn't need to test the commit functionality. If that breaks more than
        > just you will have problems.
        >
        > Hope I helped,
        >
        > Big Mike
        >
        >
        > On Wed, Jun 30, 2010 at 8:32 PM, hdave321321 <hdave321321@...> wrote:
        >
        > >
        > >
        > > My DAO integration tests are taking a long time to run. I am using Spring
        > > Test which automatically does a transaction rollback after each test method.
        > > However, I am also using DBUnit to load the exact same dataset before each
        > > test method via the @BeforeTransaction annotation.
        > >
        > > It has occured to me that I could save a lot of time if I load the DBUnit
        > > test data once per test class instead of once per test method.
        > >
        > > I've not used the @BeforeClass and @AfterClass methods before, but
        > > apparently they require the annotated method to be static and this is
        > > interfering with my normal use of Spring dependency injection that provides
        > > an application context, data source, and other things I need to load the
        > > correct data set.
        > >
        > > Anyone experience this before? What's a good way to address this problem?
        > >
        > >
        > >
        >
        >
        > [Non-text portions of this message have been removed]
        >
      • Mike Forsberg
        The hack of a initalizationOccurred boolean is always an option. In other words... use a static field that is initially set to false. Then when you come to
        Message 3 of 9 , Jul 1, 2010
        • 0 Attachment
          The hack of a initalizationOccurred boolean is always an option.

          In other words... use a static field that is initially set to false. Then
          when you come to your setup method, only do the update if the field is
          false. Just remember to set the field to true once the update occurs. This
          way, no matter which test runs first or even if a sub set of tests run, then
          the reset only occurs initially.

          There may be a better way to do this, but I like to fall back on this
          recipe.

          Big Mike

          On Thu, Jul 1, 2010 at 11:39 AM, hdave321321 <hdave321321@...> wrote:

          >
          >
          > Thanks for the help. In my case, Spring Test does an automatic transaction
          > rollback after every test method, so there are no dependencies between tests
          > -- so thats not a problem. Because of the rollback, it is also the case that
          > they order of the test runs also doesn't matter. The database is reset to a
          > "known" state after each test method by the transactional rollback.
          >
          > I'd just like to load the data once rather than 50 times. But the
          > @BeforeClass requirement to be a static method makes it impossible to use.
          > Is there any trigger that can run after a class is initialized by Spring and
          > before any test method is executed?
          >
          >
          > --- In junit@yahoogroups.com <junit%40yahoogroups.com>, Mike Forsberg
          > <bigmike.f@...> wrote:
          > >
          > > I would advise against that unless you were following the following guide
          > > lines....
          > > - No test method (or called method) manipulates the data base.
          > > - The order of the test methods do not cause conflicts with each other
          > with
          > > required data being there.
          > >
          > > Some things I'd try before doing the @BeforeClass
          > > - Only populate the data you need for a given set of tests. (Don't
          > populate
          > > the _whole_ database.)
          > > - Which of the DBUnit population features are you using... I think there
          > is
          > > one that will revert to a known state, without the delete and insert.
          > This
          > > may save some time.
          > > - Try to use a non-commitable transaction for testing. After all, one
          > > shouldn't need to test the commit functionality. If that breaks more than
          > > just you will have problems.
          > >
          > > Hope I helped,
          > >
          > > Big Mike
          > >
          > >
          > > On Wed, Jun 30, 2010 at 8:32 PM, hdave321321 <hdave321321@...> wrote:
          > >
          > > >
          > > >
          > > > My DAO integration tests are taking a long time to run. I am using
          > Spring
          > > > Test which automatically does a transaction rollback after each test
          > method.
          > > > However, I am also using DBUnit to load the exact same dataset before
          > each
          > > > test method via the @BeforeTransaction annotation.
          > > >
          > > > It has occured to me that I could save a lot of time if I load the
          > DBUnit
          > > > test data once per test class instead of once per test method.
          > > >
          > > > I've not used the @BeforeClass and @AfterClass methods before, but
          > > > apparently they require the annotated method to be static and this is
          > > > interfering with my normal use of Spring dependency injection that
          > provides
          > > > an application context, data source, and other things I need to load
          > the
          > > > correct data set.
          > > >
          > > > Anyone experience this before? What's a good way to address this
          > problem?
          > > >
          > > >
          > > >
          > >
          > >
          > > [Non-text portions of this message have been removed]
          > >
          >
          >
          >


          [Non-text portions of this message have been removed]
        • J. B. Rainsberger
          ... Let me tell you a story. In 2001 I worked on my first XP project at Toyota Canada in Toronto. We ran into exactly the same problem you describe here: we
          Message 4 of 9 , Jul 1, 2010
          • 0 Attachment
            hdave321321 wrote:

            > My DAO integration tests are taking a long time to run. I am using
            > Spring Test which automatically does a transaction rollback after
            > each test method. However, I am also using DBUnit to load the exact
            > same dataset before each test method via the @BeforeTransaction
            > annotation.
            >
            > It has occured to me that I could save a lot of time if I load the
            > DBUnit test data once per test class instead of once per test
            > method.
            >
            > I've not used the @BeforeClass and @AfterClass methods before, but
            > apparently they require the annotated method to be static and this is
            > interfering with my normal use of Spring dependency injection that
            > provides an application context, data source, and other things I need
            > to load the correct data set.
            >
            > Anyone experience this before? What's a good way to address this
            > problem?

            Let me tell you a story.

            In 2001 I worked on my first XP project at Toyota Canada in Toronto. We
            ran into exactly the same problem you describe here: we had several
            dozen tests, most of which inserted data in setUp() and rolled
            transactions back in tearDown(). Back then, of course, computers ran
            more slowly, so we were running at around 5-10 tests per second when we
            were lucky. We could see how when we added another 300 tests our test
            suite would take several minutes to run, and that just wasn't going to
            work. We decided to create a single test data set for the entire test
            suite, then used the tools of the time--DBUnit, in fact--to insert the
            data set at the start of the test run. For a few weeks, it worked great.
            Our test suite execution time dropped from minutes to tens of seconds
            which, back then, we could live with.

            Then something annoying happened.

            We added a new feature, which required putting data in a new table,
            which itself required adding a row to an old table to set up a foreign
            key relationship. We got the six new tests to run, but when we ran the
            entire suite just before checkin, 3 tests failed. We discovered that by
            adding a row to the parent table, we changed the expected result for
            three of our tests: they used to expect 6 rows, and now they needed to
            expect 7. We considered two options: split the test data into two sets,
            or change the expected results in the tests. We figured that the first
            option would slowly lead us back to loading test data for each test, so
            we chose the second option and changed the expected results.

            A couple of weeks later, it happened again. We added a feature that
            required putting data in a new table, which itself required adding rows
            to a few different existing tables to set up foreign key relationships.
            We got the eight new tests run, but when we ran the whole suite, 10
            tests failed. We sighed, we checked what happened, and we updated the
            expected results on the old tests.

            A week later, it happened again. This time we had to change 26 tests. It
            took a day to do it accurately, because each "fix" required running an
            8-minute test suite, and 26 times 8 is already over three hours.

            A week later, it happened again. This time we had to change 61 tests. It
            took three days. We saw where this was going.

            We split the test data back into sensible datasets, with each test
            loading the data it needed. Execution time increased, but maintenance
            time went to almost zero. We also figured out how to test more of the
            system without touching the database at all. Nowadays, when I work on
            such a project, only about 20-50 tests touch the database, and the rest
            run in memory. At today's machine speeds, I usually get 250-500 tests
            per second. In the ten seconds it takes for my mind to wander, I can run
            15,000-30,000 tests. I can build a pretty good system for 15,000 tests.
            --
            J. B. Rainsberger :: http://www.jbrains.ca ::
            http://www.thecodewhisperer.com
          • hdave321321
            That is a compelling story -- thanks for taking the time to tell it. We use a best practice that each test class must have its own independent test data set.
            Message 5 of 9 , Jul 2, 2010
            • 0 Attachment
              That is a compelling story -- thanks for taking the time to tell it.

              We use a best practice that each test class must have its own independent test data set. Right now we have only 8 test class and 8 test data sets. But soon we'll have 50+ test classes and so we'll have 50+ test data sets. Recall that Spring Test performs a rollback after every test method, so there are no dependencies between tests.

              In your experience, is one data set per test *class* good enough? It's unclear from your narrative if you are suggesting one data set per test *method* or just avoiding/minimizing integration testing altogether in favor of unit testing.

              I have found these DAO integration tests to be extremely helpful, given all the subtleties and magic surrounding Spring and Hibernate.





              --- In junit@yahoogroups.com, "J. B. Rainsberger" <jbrains762@...> wrote:
              >
              > hdave321321 wrote:
              >
              > > My DAO integration tests are taking a long time to run. I am using
              > > Spring Test which automatically does a transaction rollback after
              > > each test method. However, I am also using DBUnit to load the exact
              > > same dataset before each test method via the @BeforeTransaction
              > > annotation.
              > >
              > > It has occured to me that I could save a lot of time if I load the
              > > DBUnit test data once per test class instead of once per test
              > > method.
              > >
              > > I've not used the @BeforeClass and @AfterClass methods before, but
              > > apparently they require the annotated method to be static and this is
              > > interfering with my normal use of Spring dependency injection that
              > > provides an application context, data source, and other things I need
              > > to load the correct data set.
              > >
              > > Anyone experience this before? What's a good way to address this
              > > problem?
              >
              > Let me tell you a story.
              >
              > In 2001 I worked on my first XP project at Toyota Canada in Toronto. We
              > ran into exactly the same problem you describe here: we had several
              > dozen tests, most of which inserted data in setUp() and rolled
              > transactions back in tearDown(). Back then, of course, computers ran
              > more slowly, so we were running at around 5-10 tests per second when we
              > were lucky. We could see how when we added another 300 tests our test
              > suite would take several minutes to run, and that just wasn't going to
              > work. We decided to create a single test data set for the entire test
              > suite, then used the tools of the time--DBUnit, in fact--to insert the
              > data set at the start of the test run. For a few weeks, it worked great.
              > Our test suite execution time dropped from minutes to tens of seconds
              > which, back then, we could live with.
              >
              > Then something annoying happened.
              >
              > We added a new feature, which required putting data in a new table,
              > which itself required adding a row to an old table to set up a foreign
              > key relationship. We got the six new tests to run, but when we ran the
              > entire suite just before checkin, 3 tests failed. We discovered that by
              > adding a row to the parent table, we changed the expected result for
              > three of our tests: they used to expect 6 rows, and now they needed to
              > expect 7. We considered two options: split the test data into two sets,
              > or change the expected results in the tests. We figured that the first
              > option would slowly lead us back to loading test data for each test, so
              > we chose the second option and changed the expected results.
              >
              > A couple of weeks later, it happened again. We added a feature that
              > required putting data in a new table, which itself required adding rows
              > to a few different existing tables to set up foreign key relationships.
              > We got the eight new tests run, but when we ran the whole suite, 10
              > tests failed. We sighed, we checked what happened, and we updated the
              > expected results on the old tests.
              >
              > A week later, it happened again. This time we had to change 26 tests. It
              > took a day to do it accurately, because each "fix" required running an
              > 8-minute test suite, and 26 times 8 is already over three hours.
              >
              > A week later, it happened again. This time we had to change 61 tests. It
              > took three days. We saw where this was going.
              >
              > We split the test data back into sensible datasets, with each test
              > loading the data it needed. Execution time increased, but maintenance
              > time went to almost zero. We also figured out how to test more of the
              > system without touching the database at all. Nowadays, when I work on
              > such a project, only about 20-50 tests touch the database, and the rest
              > run in memory. At today's machine speeds, I usually get 250-500 tests
              > per second. In the ten seconds it takes for my mind to wander, I can run
              > 15,000-30,000 tests. I can build a pretty good system for 15,000 tests.
              > --
              > J. B. Rainsberger :: http://www.jbrains.ca ::
              > http://www.thecodewhisperer.com
              >
            • hdave321321
              I am totally good with hacks! However, this one still leaves me with a problem. I still need to delete the test data after all the tests have run! The only
              Message 6 of 9 , Jul 2, 2010
              • 0 Attachment
                I am totally good with hacks! However, this one still leaves me with a problem. I still need to delete the test data after all the tests have run! The only way to do this is via @AfterClass which, again, forces all my DBUnit code to be static which doesn't work.

                In the meantime, I implemented another approach that has seemed to work. I created a non-static DBUnitHelper class and used Spring to instantiate one of these and inject it into the root class of my test classes. The DBUnitHelper class uses your approach to ensure the data is only loaded once regardless of how many times it is asked to load it. Deleting the data from an @AfterClass static method was also simple. So for now, I am happy.

                For the record, an alternative (and better) approach I learned about elsewhere is to do what unitils does and create a custom testexecutionlistener.

                Also for the record, if you annotate a method with @PostConstruct -- it's also a great way to load the data just once. However, you are still left with the cleanup problem....

                Anyway hope all this helps somebody else!

                --- In junit@yahoogroups.com, Mike Forsberg <bigmike.f@...> wrote:
                >
                > The hack of a initalizationOccurred boolean is always an option.
                >
                > In other words... use a static field that is initially set to false. Then
                > when you come to your setup method, only do the update if the field is
                > false. Just remember to set the field to true once the update occurs. This
                > way, no matter which test runs first or even if a sub set of tests run, then
                > the reset only occurs initially.
                >
                > There may be a better way to do this, but I like to fall back on this
                > recipe.
                >
                > Big Mike
                >
                > On Thu, Jul 1, 2010 at 11:39 AM, hdave321321 <hdave321321@...> wrote:
                >
                > >
                > >
                > > Thanks for the help. In my case, Spring Test does an automatic transaction
                > > rollback after every test method, so there are no dependencies between tests
                > > -- so thats not a problem. Because of the rollback, it is also the case that
                > > they order of the test runs also doesn't matter. The database is reset to a
                > > "known" state after each test method by the transactional rollback.
                > >
                > > I'd just like to load the data once rather than 50 times. But the
                > > @BeforeClass requirement to be a static method makes it impossible to use.
                > > Is there any trigger that can run after a class is initialized by Spring and
                > > before any test method is executed?
                > >
                > >
                > > --- In junit@yahoogroups.com <junit%40yahoogroups.com>, Mike Forsberg
                > > <bigmike.f@> wrote:
                > > >
                > > > I would advise against that unless you were following the following guide
                > > > lines....
                > > > - No test method (or called method) manipulates the data base.
                > > > - The order of the test methods do not cause conflicts with each other
                > > with
                > > > required data being there.
                > > >
                > > > Some things I'd try before doing the @BeforeClass
                > > > - Only populate the data you need for a given set of tests. (Don't
                > > populate
                > > > the _whole_ database.)
                > > > - Which of the DBUnit population features are you using... I think there
                > > is
                > > > one that will revert to a known state, without the delete and insert.
                > > This
                > > > may save some time.
                > > > - Try to use a non-commitable transaction for testing. After all, one
                > > > shouldn't need to test the commit functionality. If that breaks more than
                > > > just you will have problems.
                > > >
                > > > Hope I helped,
                > > >
                > > > Big Mike
                > > >
                > > >
                > > > On Wed, Jun 30, 2010 at 8:32 PM, hdave321321 <hdave321321@> wrote:
                > > >
                > > > >
                > > > >
                > > > > My DAO integration tests are taking a long time to run. I am using
                > > Spring
                > > > > Test which automatically does a transaction rollback after each test
                > > method.
                > > > > However, I am also using DBUnit to load the exact same dataset before
                > > each
                > > > > test method via the @BeforeTransaction annotation.
                > > > >
                > > > > It has occured to me that I could save a lot of time if I load the
                > > DBUnit
                > > > > test data once per test class instead of once per test method.
                > > > >
                > > > > I've not used the @BeforeClass and @AfterClass methods before, but
                > > > > apparently they require the annotated method to be static and this is
                > > > > interfering with my normal use of Spring dependency injection that
                > > provides
                > > > > an application context, data source, and other things I need to load
                > > the
                > > > > correct data set.
                > > > >
                > > > > Anyone experience this before? What's a good way to address this
                > > problem?
                > > > >
                > > > >
                > > > >
                > > >
                > > >
                > > > [Non-text portions of this message have been removed]
                > > >
                > >
                > >
                > >
                >
                >
                > [Non-text portions of this message have been removed]
                >
              • Bogdan
                Just like PostConstruct, you also have the PreDestroy annotation. Annotating a method with this will allow you to execute code before the respective bean is
                Message 7 of 9 , Jul 4, 2010
                • 0 Attachment
                  Just like PostConstruct, you also have the PreDestroy annotation. Annotating a method with this will allow you to execute code before the respective bean is taken out of the context.

                  More generaly, you could implement (if you don't already have) a Spring bean that is responsible with setting up the test, and then cleaning up when the tests are finished. Having this bean as a Spring singleton ensures that the bean will be created only once, and the initialization + destruction methods will also be called only once.

                  Bogdan

                  --- In junit@yahoogroups.com, "hdave321321" <hdave321321@...> wrote:
                  >
                  > I am totally good with hacks! However, this one still leaves me with a problem. I still need to delete the test data after all the tests have run! The only way to do this is via @AfterClass which, again, forces all my DBUnit code to be static which doesn't work.
                  >
                  > In the meantime, I implemented another approach that has seemed to work. I created a non-static DBUnitHelper class and used Spring to instantiate one of these and inject it into the root class of my test classes. The DBUnitHelper class uses your approach to ensure the data is only loaded once regardless of how many times it is asked to load it. Deleting the data from an @AfterClass static method was also simple. So for now, I am happy.
                  >
                  > For the record, an alternative (and better) approach I learned about elsewhere is to do what unitils does and create a custom testexecutionlistener.
                  >
                  > Also for the record, if you annotate a method with @PostConstruct -- it's also a great way to load the data just once. However, you are still left with the cleanup problem....
                  >
                  > Anyway hope all this helps somebody else!
                  >
                  > --- In junit@yahoogroups.com, Mike Forsberg <bigmike.f@> wrote:
                  > >
                  > > The hack of a initalizationOccurred boolean is always an option.
                  > >
                  > > In other words... use a static field that is initially set to false. Then
                  > > when you come to your setup method, only do the update if the field is
                  > > false. Just remember to set the field to true once the update occurs. This
                  > > way, no matter which test runs first or even if a sub set of tests run, then
                  > > the reset only occurs initially.
                  > >
                  > > There may be a better way to do this, but I like to fall back on this
                  > > recipe.
                  > >
                  > > Big Mike
                  > >
                  > > On Thu, Jul 1, 2010 at 11:39 AM, hdave321321 <hdave321321@> wrote:
                  > >
                  > > >
                  > > >
                  > > > Thanks for the help. In my case, Spring Test does an automatic transaction
                  > > > rollback after every test method, so there are no dependencies between tests
                  > > > -- so thats not a problem. Because of the rollback, it is also the case that
                  > > > they order of the test runs also doesn't matter. The database is reset to a
                  > > > "known" state after each test method by the transactional rollback.
                  > > >
                  > > > I'd just like to load the data once rather than 50 times. But the
                  > > > @BeforeClass requirement to be a static method makes it impossible to use.
                  > > > Is there any trigger that can run after a class is initialized by Spring and
                  > > > before any test method is executed?
                  > > >
                  > > >
                  > > > --- In junit@yahoogroups.com <junit%40yahoogroups.com>, Mike Forsberg
                  > > > <bigmike.f@> wrote:
                  > > > >
                  > > > > I would advise against that unless you were following the following guide
                  > > > > lines....
                  > > > > - No test method (or called method) manipulates the data base.
                  > > > > - The order of the test methods do not cause conflicts with each other
                  > > > with
                  > > > > required data being there.
                  > > > >
                  > > > > Some things I'd try before doing the @BeforeClass
                  > > > > - Only populate the data you need for a given set of tests. (Don't
                  > > > populate
                  > > > > the _whole_ database.)
                  > > > > - Which of the DBUnit population features are you using... I think there
                  > > > is
                  > > > > one that will revert to a known state, without the delete and insert.
                  > > > This
                  > > > > may save some time.
                  > > > > - Try to use a non-commitable transaction for testing. After all, one
                  > > > > shouldn't need to test the commit functionality. If that breaks more than
                  > > > > just you will have problems.
                  > > > >
                  > > > > Hope I helped,
                  > > > >
                  > > > > Big Mike
                  > > > >
                  > > > >
                  > > > > On Wed, Jun 30, 2010 at 8:32 PM, hdave321321 <hdave321321@> wrote:
                  > > > >
                  > > > > >
                  > > > > >
                  > > > > > My DAO integration tests are taking a long time to run. I am using
                  > > > Spring
                  > > > > > Test which automatically does a transaction rollback after each test
                  > > > method.
                  > > > > > However, I am also using DBUnit to load the exact same dataset before
                  > > > each
                  > > > > > test method via the @BeforeTransaction annotation.
                  > > > > >
                  > > > > > It has occured to me that I could save a lot of time if I load the
                  > > > DBUnit
                  > > > > > test data once per test class instead of once per test method.
                  > > > > >
                  > > > > > I've not used the @BeforeClass and @AfterClass methods before, but
                  > > > > > apparently they require the annotated method to be static and this is
                  > > > > > interfering with my normal use of Spring dependency injection that
                  > > > provides
                  > > > > > an application context, data source, and other things I need to load
                  > > > the
                  > > > > > correct data set.
                  > > > > >
                  > > > > > Anyone experience this before? What's a good way to address this
                  > > > problem?
                  > > > > >
                  > > > > >
                  > > > > >
                  > > > >
                  > > > >
                  > > > > [Non-text portions of this message have been removed]
                  > > > >
                  > > >
                  > > >
                  > > >
                  > >
                  > >
                  > > [Non-text portions of this message have been removed]
                  > >
                  >
                • J. B. Rainsberger
                  ... You re most welcome. ... I err on the side of one data set to test (method), however if a handful (six?) of tests share a data set, I can live with that.
                  Message 8 of 9 , Jul 15, 2010
                  • 0 Attachment
                    hdave321321 wrote:

                    > That is a compelling story -- thanks for taking the time to tell it.

                    You're most welcome.

                    > We use a best practice that each test class must have its own
                    > independent test data set. Right now we have only 8 test class and 8
                    > test data sets. But soon we'll have 50+ test classes and so we'll have
                    > 50+ test data sets. Recall that Spring Test performs a rollback after
                    > every test method, so there are no dependencies between tests.
                    >
                    > In your experience, is one data set per test *class* good enough? It's
                    > unclear from your narrative if you are suggesting one data set per test
                    > *method* or just avoiding/minimizing integration testing altogether in
                    > favor of unit testing.

                    I err on the side of one data set to test (method), however if a handful
                    (six?) of tests share a data set, I can live with that. As long as
                    changes in a data set don't lead to changes in seemingly irrelevant
                    tests, I wouldn't worry too much.

                    Bear in mind that I have the style of making many little things, then
                    collecting them together, instead of making big things and breaking them
                    up when they grow too big, so this might boil down to a style issue.

                    > I have found these DAO integration tests to be extremely helpful, given
                    > all the subtleties and magic surrounding Spring and Hibernate.

                    Have you found much duplication in your integrated tests?
                    --
                    J. B. Rainsberger :: http://www.jbrains.ca ::
                    http://www.thecodewhisperer.com
                  Your message has been successfully submitted and would be delivered to recipients shortly.