c******n
发帖数: 4965 | 1 our previous developers just use our one and only single QA db, and assume
that the content is so and so, but over time, the content changes, so the
test cases all gradually fail..
what is your strategy in this case? | g*****g
发帖数: 34805 | 2 Use an embeded DB for testing purpose, clean and populate test data for
each test case.
【在 c******n 的大作中提到】
: our previous developers just use our one and only single QA db, and assume
: that the content is so and so, but over time, the content changes, so the
: test cases all gradually fail..
: what is your strategy in this case?
| c******n
发帖数: 4965 | 3 but since the data is a HUGE (probably 300 nodes ) object graph,
probably inserting just one entry in a table would require us to put in
all the associated objects , constrained by foreign keys.
essentially we'd have to keep the entire DB dump for every release of the
test code.
true, this db dump can be very small, for derby or something
【在 g*****g 的大作中提到】
: Use an embeded DB for testing purpose, clean and populate test data for
: each test case.
| g*****g
发帖数: 34805 | 4 Populate just enough data for testing purpose, you don't need to
maintain the test data between tests, that's what a unit test
is supposed to be. If that's not feasible, you are looking into
external DB depnedency and integration test instead.
【在 c******n 的大作中提到】
: but since the data is a HUGE (probably 300 nodes ) object graph,
: probably inserting just one entry in a table would require us to put in
: all the associated objects , constrained by foreign keys.
: essentially we'd have to keep the entire DB dump for every release of the
: test code.
: true, this db dump can be very small, for derby or something
| c******n
发帖数: 4965 | 5 actually sometimes we need to go back to a previous version (back out some
changes), then if you don't keep the data source (a db dump ) in svn, when
you back out later changes, the old tests will fail
【在 g*****g 的大作中提到】
: Populate just enough data for testing purpose, you don't need to
: maintain the test data between tests, that's what a unit test
: is supposed to be. If that's not feasible, you are looking into
: external DB depnedency and integration test instead.
| g*****g
发帖数: 34805 | 6 That's why you keep the schema and the data with the tests.
Different tests can use different schema and data if you wish.
【在 c******n 的大作中提到】
: actually sometimes we need to go back to a previous version (back out some
: changes), then if you don't keep the data source (a db dump ) in svn, when
: you back out later changes, the old tests will fail
| S****h
发帖数: 558 | 7 There is a tool called dbunit. It can export the data (maybe also schema)
from database as xml and repopulate the database. Probably it can stand
for some schema change. http://www.dbunit.org/. It might be useful for you.
【在 c******n 的大作中提到】
: our previous developers just use our one and only single QA db, and assume
: that the content is so and so, but over time, the content changes, so the
: test cases all gradually fail..
: what is your strategy in this case?
| c******n
发帖数: 4965 | 8 pretty neat, thanks!
【在 S****h 的大作中提到】
: There is a tool called dbunit. It can export the data (maybe also schema)
: from database as xml and repopulate the database. Probably it can stand
: for some schema change. http://www.dbunit.org/. It might be useful for you.
| r*****s
发帖数: 985 | 9 理论上是个好办法，
实践上
maintaining the seed data is a headache,
especially with multiple types of dbs.
adding another db, like derby, becomes
a burden to both devs and dba, what made
it worse was that derby differs from other
dbs like mysql in some behaviors
(transaction? i forgot) and thus the unit tests
thread with the embedded db were evetually
abandoned.
【在 g*****g 的大作中提到】
: Use an embeded DB for testing purpose, clean and populate test data for
: each test case.
|
|
