It's better:
You have narrowed your over-ripe test by extracting one extra piece of common code, or in other words, one extra juicy bit. Now you are executing those juicy bits far fewer times (you usually find
a lot of exact duplicates), so your tests run faster. And each one will fail for fewer reasons.
It's also no worse:
You have created a new test for what you extracted that verifies exactly what had been verified before. This means you don't lose any coverage.
Benefits:
- Test suite runs faster.
- Stories get done faster because you fix fewer false failures.
- Ship fewer bugs because you listen to your test failures.
Downsides:
- The setup in ripe tests can get out of sync with the assertions in your new juice test. This can result in integration bugs that make it past your test suite.
Solving the downside (optional)
First, make sure it's an actual problem in this case. Most code code that used in setting up many tests changes rarely, so it may be cheaper to keep the risk than to fix it.
If it is a problem, then
1) use extract method on the setup statements from the ripe test,
2) extract method the assertions from the juice test, and
3) create a new test that calls the setup method and the assertion method. This verifies that your ripe setup will stay in sync with your juice tests.
Going too far
This can get out of hand. You might see partial duplication between setup methods, so you desire to merge them or to create a smart builder.
Don't do it! You are seeing a ripple of one of your god classes. Fix the god class' interaction with this test instead.