4 ms·
The hard parts to design about this, imo, are: - How to reconcile this with tests that execute many times with varying input data. You’d need some way to expre
by drdexebtjl 2mo ago
The hard parts to design about this, imo, are:
- How to reconcile this with tests that execute many times with varying input data. You’d need some way to express requirements with specific inputs or shared inputs.
- Passing state between test dependencies.
- When, if ever, it’s fine to share step results between tests. If tests B and C require A, can you run A just once? Not always, but you should be able to when it’s safe.
I don’t think I’ve ever used a test framework that gets these things right.
- RHSeeger 2mo ago> Passing state between test dependencies Actually, I wasn't even thinking about passing state. I was thinking about shared setup steps. I'm perfectly happy for the same steps to run for each test - as long as each test doesn't need to list the steps (when they're setup steps not directly related to the thing being tested)
- drdexebtjl 2mo agoFor example, suppose you want to write a test for the shipOrder(orderId) function, and you want it to depend on the test for the placeOrder(shoppingCart) -> OrderId function. Even if you are fine calling placeOrder twice, once for the placeOrder test and once for the placeOrderAndShipOrder test, you still need the placeOrder test to provide an order ID to the second test, and not just a confirmation that it completed successfully.