Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You could create a base test class, put the login in its <code>setUp()</code> and inherit all your test cases from this one (and of course, call <code>super.setUp()</code> everywhere).</p> <p>Note that this would only be a simple login, not a proper unit test. You should unit test your login functionality with all possible crazy user input and whatnot in a separate test class, but for the rest of the test cases you only need a plain simple login with a default username or something.</p> <p>For those test cases where on top of login you need a product as well, you create a second base test class which extends the first and adds product creation to its <code>setUp()</code>.</p> <p>No code duplication - if login changes, apart from the login test cases themselves you need to change a single method in your test code.</p> <p>It will probably be slower to execute 5000 unit tests this way - but much, much safer. If you start to depend on the order of execution of your unit tests, you're stepping on a slippery slope. It is very difficult to notice that you have inadvertently introduced an extra dependency between two unit tests if their order is fixed by your configuration. E.g. you set up a specific property of a product or change a global configuration setting in one unit test, then you test something else on your product in the next test case - and it happens to work only because the previous unit test set things up that specific way. This leads to nasty suprises sooner or later.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload