New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@ExpectedDatabase value attribute input two or more requests #64

Closed
bluepoet opened this Issue Jan 16, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@bluepoet

bluepoet commented Jan 16, 2015

I think the @ExpectedDatabase annotations added every table gon inconvenience .
@DatabaseSetup Annotations as two or more requests to enter the value attribute.

@philwebb

This comment has been minimized.

Contributor

philwebb commented Jan 21, 2015

I'm afraid I'm not following what you mean, could you rephrase?

@bluepoet

This comment has been minimized.

bluepoet commented Feb 11, 2015

@philwebb I think the trouble is that "@ExpectedDatabase" annotations are used for every table. It would be nice if you could put more than one value in the value attribute with the "@DatabaseSetup" annotation.

@philwebb

This comment has been minimized.

Contributor

philwebb commented Feb 19, 2015

So you would like the String value() attribute of @ExpectedDatabase to be String[] value()?

Have you seen the @ExpectedDatabases annotation that was added to the latest release?

@bluepoet

This comment has been minimized.

bluepoet commented Feb 24, 2015

@philwebb I have resolved to write @ExpectedDatabases like the following code to set the override attribute to a false @ExpectedDatabase.

@ExpectedDatabases ({
@ExpectedDatabase (AssertionMode =DatabaseAssertionMode.NON_STRICT, value ="a.xml"), @ExpectedDatabase (AssertionMode = DatabaseAssertionMode.NON_STRICT, value ="b.xml", override = false)})

Thank you @philwebb

@calle2010

This comment has been minimized.

calle2010 commented Mar 7, 2016

Hello, I think I ran into the same issue that @bluepoet encountered and worked around using override=false:

I found that @ExpectedDatabase is @repeatable, but in a test that should fail it depended on the order of the annotations on the method:

@DatabaseSetup("setup_ParentSpring.xml")
@DatabaseSetup("setup_ChildSpring.xml")
@ExpectedDatabase(value = "setup_ChildSpring.xml", assertionMode = DatabaseAssertionMode.NON_STRICT_UNORDERED)
@ExpectedDatabase(value = "expect_ParentSpring_updated.xml", assertionMode = DatabaseAssertionMode.NON_STRICT_UNORDERED)

The test method is actually empty, so the expectation is that the annotation with expect_ParentSpring_updated.xml fails the test, since no update happens.

But if I change the order of the @ExpectedDatabase annotations, the test succeeds:

@DatabaseSetup("setup_ParentSpring.xml")
@DatabaseSetup("setup_ChildSpring.xml")
@ExpectedDatabase(value = "expect_ParentSpring_updated.xml", assertionMode = DatabaseAssertionMode.NON_STRICT_UNORDERED)
@ExpectedDatabase(value = "setup_ChildSpring.xml", assertionMode = DatabaseAssertionMode.NON_STRICT_UNORDERED)

By checking the code I found that verification stops if one annotation has the override flag set to true, which is the default for @ExpectedDatabase, see

In this case, the last annotation is evaluated first and, since override==true, stops further verification.

I think the concept needs refinement or this behavior should be documented.

Workaround is, like @bluepoet wrote, to set override=false on the annotations after the the first (or all, if no class level annotation has been done).

@ExpectedDatabases annotation doesn't help since it shows the same issue.

calle2010 added a commit to calle2010/testJpa that referenced this issue Mar 7, 2016

change all DBUnit test to rollback
DBUnit works as advertised but needs an EntityManager.flush() at
the end of test methods which modify data.

Multiple @ExpectedDatabases annotations override each other, see
springtestdbunit/spring-test-dbunit#64 (comment)

Remove @DirtiesContext and other work-arounds since this is not
needed anymore for the DBUnit tests. Tests run faster since
Spring can re-use the test context.

@philwebb philwebb closed this in 1a5a41b Apr 14, 2016

@philwebb philwebb added this to the 1.3.0 milestone Apr 15, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment