springtestdbunit / spring-test-dbunit

Integration between the Spring testing framework and DBUnit
http://springtestdbunit.github.com/spring-test-dbunit/
Apache License 2.0
476 stars 238 forks source link

Setup database once per whole test class #40

Open koiuo opened 11 years ago

koiuo commented 11 years ago

Hi Phillip, Mario. I use spring-test-dbunit on most of my projects. I like its declarative approach and how it reduces amount of boilerplate code.

Though, spring-test-dbunit lacks ability to perform database setup only once for the whole test class. Often it is required to test some read-only dao. Performing database setup in separate transaction before each test method would require very long time (depending on dataset size and current database state).

In my fork I've added POC implementation of such feature. It is implemented via dedicated TestExecutionListener and reuses existing annotations.

https://github.com/edio/spring-test-dbunit/commit/5023c0b82b38f6ab262063e57cb7dffda269083c

I would like to know, what do you think about such feature in general. Is there any chance you could consider adding it to your framework? Also, let me know, please, what do you think about my current approach. I'm eager to contribute to your project and would appreciate any comments/suggestions.

Thanks.

philwebb commented 10 years ago

Hi @edio,

Sorry about taking so long to respond.

The approach looks interesting but I wonder if it might be worth attacking this a two separate problems:

1) Allow @DatabaseSetup and @DatabaseTearDown to run only once per test class. We could add an additional attribute to indicate that the annotation should only run once per class, instead of on each test method. This might be generally useful if you don't use transactions at all. You could setup your database at the start of the test, run each method and then clean it up.

2) Create TransactionalTestExecutionListener that starts/rollbacks only once per test This might even be a sensible contribution to Spring itself. You might also be able to delegate to the existing TransactionalTestExecutionListener, rather than needing to duplicate so much of the existing code.

I have started working on v1.1 in master so it might be worth trying to rebase your POC.

imod commented 10 years ago

+1 as this did not make it into 1.1, I'l whrite my own JUnitRule I guess...

raystorm commented 9 years ago

+1 from me too. for whatever that's worth.

bruce264 commented 9 years ago

+1 This would be a very useful feature

ekravchenko commented 9 years ago

Hi guys,

In DBSetup guys from NinjaSuad skip inserting data for tests if they are read-only. dbSetupTracker.skipNextLaunch();

What if we could introduce @ReadOnly annotation on tests (test methods)? In that case we could mix 'read-only' and non read-only tests inside test class. That might be tricky to implement cause the runner would have to run 'read-only' tests first, saving time to insert and cleanup DB data. After that all non-readonly tests could be fired.

Thanks.

tpuica commented 7 years ago

+1 we have a class with many test methods and a large data set that needs 1 hour to complete (the database setup takes ~3 minutes)

amartin-parkeon commented 6 years ago

+1

a-rr commented 5 years ago

+1 Even a new annotation... Another test case: arquillian allows to run test methods in order. In a functional test, you could split stages of user navigation (as a user history). Reloading data everytime is slow, and can compromise data the user has already registered.