Forum Discussion
How are all testitems designed to run on their own and not depend on another?
- they all start with a defined state
- there are 2 defined starting-states in our testitems: either a new and empty database is created at the start of the testitem or an existing database is restored
- often we import specified data (this is possible in our software, e.g. from an excel file that is also under version control)
- afterwards they all start the browser and log in
If a record is added in a testitem and not removed how can the test be run again without creating a duplicate?
- see above
- additionally we do some preparing work at the start of the project suite (e.g. installing the program, deleting all existing databases, terminating some processes...) (setup: ~9 minutes)
- additionally we have a onStartTest routine running at the start of each testitem (terminating browser, terminating processes,...) (onStartTest: ~2-5 seconds)
- we also have a onStopTest-Routine (~1-3 seconds) and a teardown project that clears all stuff at the end of the project suite (~20-30 seconds)
- no testitem is run twice. there is no need for that in our case. and if so, we would take care about a defined state at the start of the testitem (see above)
If there are dependencies (i.e. supplier / product / purchase / receive / customer / sale / receivable...)
how can individual testitems be descrete and reusable and run on their own?
- I do not get what dependencies this could be, but I try to guess.
- e.g. we have a database that we restore where a webservice-connector or other connectors are already defined
- we have surrounding testenvironment that provides data (some vm sontaining ppm-systems, excel files, webservices,...) that is either under version control or must not be changed at all.
- is it this what you meant?
Additionally we make sure that a failed testitem does not at all affect following testitems.
We therefore wrote our own Runner.nextTestitem(...) routine that skips the current testitem and starts the next. This routine is called when some inproper state is detected (restoring database failed, timeout is over,...). This routine combined with the onStartTest and onStopTest routines guarantee us that this is working perfectly well.
We were able to make the developers take responsibility for manual testing, code reviews, unit tests and integration tests. Now the last step is coming that the developers also should do the automated regression testing.
No, the last step should be - to make the developers take responsibility for making the coffee for testers :)
(I'm just kidding. Thank you for your detailed feedback)
- william_roe10 years agoSuper Contributor
baxatob wrote:We were able to make the developers take responsibility for manual testing, code reviews, unit tests and integration tests. Now the last step is coming that the developers also should do the automated regression testing.
No, the last step should be - to make the developers take responsibility for making the coffee for testers :)
(I'm just kidding. Thank you for your detailed feedback)
The better the automated testing the lazier developers become :smileytongue: