[
https://issues.apache.org/jira/browse/OFBIZ-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858556#action_12858556
]
Bob Morley commented on OFBIZ-3663:
-----------------------------------
I am not convinced this is the problem at all -- the one failure I would point
to is EntityTestSuite.testMakeValue which creates four "TestingType" entities
and executes to get exactly 4 back. The trouble is that the "test data files"
in service/testdef/data also create "TestingType" entities in the database and
they do not appear to be doing a rollback. So a couple of things --
a) Tests only work because (by happenstance) the entity test suite runs before
the services related tests based on how the testdefs are loaded in.
b) On subsequent run, the entity test suite now gets 13 "TestingTypes" the 9
provided by the services and its own set of 4
The short-term solution would be to make the entity test more intelligent.
(aka find how many are there pre-create, do your create, make sure you have 4
more than what you started with).
A different solution would be to enhance "servicetests" such that the
"<entity-xml action="load"
entity-xml-url="component://service/testdef/data/ServiceTestData.xml"/>" can
have an equivalent "finally" step with action "unload" or something similar to
clean these things up.
But in general, I think it is a better practice to have a self-contained unit
test that is well behaved typically cleaning up after itself via a rollback.
This is different from integration or acceptance tests that would potentially
build on each other.
> Re-executing the tests cause unit test failures
> -----------------------------------------------
>
> Key: OFBIZ-3663
> URL: https://issues.apache.org/jira/browse/OFBIZ-3663
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
> Affects Versions: SVN trunk
> Reporter: Bob Morley
> Fix For: SVN trunk
>
>
> After a successful unit test run (from completely empty derby database) I
> attempted a re-execution of the tests after some programming changes. A
> number of tests started to fail (I think 4) which I believe were in the
> Accounting area (but I could be wrong on that). Test execution ideally
> should cause no state change to the database, but at a minimum should not
> fail if executed more than one time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
