Some friends introduced me to QBASIC in high school. Now I'm a software engineer and a guitar student. On weekends, you can find me at a parkrun, tending to my veggie patch or the six resident chooks.
Nice article! I think both approaches have their trade offs. Sure the social test has less lines of code, but it also "relies" on PricingEngine working correctly. Don't get me wrong - that could be totally fine too!
If you were using the social unit test approach, would you also have a separate test just for PricingEngine.calculatePrice?
Just another developer trying to get his tests fast, his features to add value and his bloody code to compile! Lately I've been enjoying writing about the best way to release software!
Yep I think they both have their merits.
But the trade-off as I see it is, would you rather:
1) needing to change the tests for all the classes that depend on yours, when you change a method signature (or move it entirely)
OR
2) Have the occasional extra test break, when you actually make a breaking change to functionality?
With regards to PricingEngine, it probably depends on how complicated it is... But I would usually expect it to have its own set of tests... Though I did always like the idea of testing functionality in groups rather than classes... Since classes can change and be refactored away.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article! I think both approaches have their trade offs. Sure the social test has less lines of code, but it also "relies" on
PricingEngineworking correctly. Don't get me wrong - that could be totally fine too!If you were using the social unit test approach, would you also have a separate test just for
PricingEngine.calculatePrice?Yep I think they both have their merits.
But the trade-off as I see it is, would you rather:
1) needing to change the tests for all the classes that depend on yours, when you change a method signature (or move it entirely)
OR
2) Have the occasional extra test break, when you actually make a breaking change to functionality?
With regards to PricingEngine, it probably depends on how complicated it is... But I would usually expect it to have its own set of tests... Though I did always like the idea of testing functionality in groups rather than classes... Since classes can change and be refactored away.