I’m quite convinced that the path to startup success is to do one, and only one, thing. And do it well. (If not awesomely.) The same thing holds true for your automated tests.

Imagine you have an application that has the idea of a logged-in user, and a non-logged in user. Some of your scripts will be around the login process, and some, the vast majority in fact, will be for some activity once you are logged in. The trick is to completely separate the two.

The first bunch of tests you produce will be around the the login process proper. These will have method names like testGoodLogin, testBadPassword, testFiveFailedLogins, testAccountLocked, etc.. They all test individual slices of the login process and both can and should fail a test if something is amiss.

And then there is all the other tests. But they all require you to login first. Well, DRY says that you should just call the testGoodLogin with the desired credentials and be done with it. Except now you have created a situation where something external to what you wanted could fail a test. Which is undesirable. What you want to do is create a helper method which will do a login for you. It will still likely have asserts in the method for page element timing and such, but if something goes wrong it won’t fail your test. Don’t necessarily ignore failing asserts, but error the script rather than fail it. We can debug the why of the error using the proper login tests.

Now, this is somewhat anti-DRY since you have a login being done in a test as well as in a helper and when the login flow changes you have multiple place to change, but that DRY a heuristic and so can be broken when appropriate.