> I wouldn't say that isolation and realism are completely orthogonal
Neither would I. I'm arguing that when you write a test method, you deliberately make the choice to include some kind of 'before-all' method, or not.
The reasons you would choose to include a 'before-all' method will vary from case to case. Let's say you're testing an addUser method. If you choose to isolate its state to avoid 'test flakiness', it is you making the call that addUser is flaky when run against shared state.
What is it about your application code that would make you think that addUser is flaky enough to need a clean slate to run against? Why not change the application code instead?
>The reasons you would choose to include a 'before-all' method will vary from case to case.
Not really. I would always purge anything that would cause tests to share state. I wouldn't do it on a case by case basis.
>What is it about your application code that would make you think that addUser is flaky enough to need a clean slate to run against?
The user already existing in the database? The behavior of the app would change in that case. Something has to wipe the db clean to test that scenario.
Neither would I. I'm arguing that when you write a test method, you deliberately make the choice to include some kind of 'before-all' method, or not.
The reasons you would choose to include a 'before-all' method will vary from case to case. Let's say you're testing an addUser method. If you choose to isolate its state to avoid 'test flakiness', it is you making the call that addUser is flaky when run against shared state.
What is it about your application code that would make you think that addUser is flaky enough to need a clean slate to run against? Why not change the application code instead?