5 ms·
The pattern can work, but the domain matters, the test type matters (unit, integration, ui) and the trade-off associated matter. e.g. If I am running a long-ru
by avensec 1mo ago
The pattern can work, but the domain matters, the test type matters (unit, integration, ui) and the trade-off associated matter.
e.g. If I am running a long-running UI-test scenario, I absolutely don't want test-5 to walk through 80% of the UI that was already exercised in tests 1-4. I am creating test coupling, but I'm saving cost/time by doing so.
But, you'll also hear why not to do this, because it creates test coupling / breaks atomic tests, which is generally seen as bad.
If that is a local integration test and those early steps run is millis? Then maybe we keep things uncoupled to allow the system to exercise the pathways without explicit expectations.
- RHSeeger 1mo agoThe question was less about speed and more about not having the same code duplicated over and over across tests. Which is how I read the article talking about it. Allowing one test to "depend" on another makes it clear they use the same setup (presumably with the second test going "a bit further", but not necessarily). I wouldn't have a problem with something like test-1: setup: do-the-thing verification assert-the-thing-happened test-2 setup: depends-on: test-1 // tells it to run test-1's setup do-the-next-thing verification assert-the-next-thing-happened The format is awful, but the idea is that most tests are of the form GIVEN Some initial setup WHEN I run command THEN The result of that command is what is expected And, in that context, the GIVEN frequently contains noise not directly related to understanding what is being tested. I actually use the GIVEN/WHEN/THEN keywords in my tests, to make them easier to read