Skip to main content
added 536 characters in body
Source Link

Your test would be simpler if they all start from known good position. Don't attempt recovery: any such effort will be inherently fragile.

  • Test might fail in subtle unanticipated ways making recovery wrong (for that failure only), causing following tests to fail.
  • You may have a bug in recovery code, making following valid tests fail.
  • end product of the test run will change, so you will have to change (and debug) the recovery.

You will waste time fixing recovery code. Instead, spend time to make flushing all changes made by test and starting with "clean slate" faster. It scales better.

Compared to unit test, UI test are harder to make independent, so I just tend to make fewer but longer running test. Some of my functional tests run for 10 minutes or more, because it takes a long time to prepare set of conditions to be tested.

So it is hard choice to start new test (which might require long run to prepare conditions), or just pile up new tested feature on top of another test which already made necessary efforts to prepare the conditions.

Your test would be simpler if they all start from known good position.

Compared to unit test, UI test are harder to make independent, so I just tend to make fewer but longer running test. Some of my functional tests run for 10 minutes or more, because it takes a long time to prepare set of conditions to be tested.

So it is hard choice to start new test (which might require long run to prepare conditions), or just pile up new tested feature on top of another test which already made necessary efforts to prepare the conditions.

Your test would be simpler if they all start from known good position. Don't attempt recovery: any such effort will be inherently fragile.

  • Test might fail in subtle unanticipated ways making recovery wrong (for that failure only), causing following tests to fail.
  • You may have a bug in recovery code, making following valid tests fail.
  • end product of the test run will change, so you will have to change (and debug) the recovery.

You will waste time fixing recovery code. Instead, spend time to make flushing all changes made by test and starting with "clean slate" faster. It scales better.

Compared to unit test, UI test are harder to make independent, so I just tend to make fewer but longer running test. Some of my functional tests run for 10 minutes or more, because it takes a long time to prepare set of conditions to be tested.

So it is hard choice to start new test (which might require long run to prepare conditions), or just pile up new tested feature on top of another test which already made necessary efforts to prepare the conditions.

Source Link

Your test would be simpler if they all start from known good position.

Compared to unit test, UI test are harder to make independent, so I just tend to make fewer but longer running test. Some of my functional tests run for 10 minutes or more, because it takes a long time to prepare set of conditions to be tested.

So it is hard choice to start new test (which might require long run to prepare conditions), or just pile up new tested feature on top of another test which already made necessary efforts to prepare the conditions.