The Old Test Pyramid tells you that Unit Tests are most important. But I'll reveal to you a "secret": in Legacy Code, you should NOT start with Unit Tests.
- Starting with Acceptance Tests is high-ROI, low-risk & low-resistance.
- Starting with Unit Tests is low-ROI, high-risk & high-resistance.
It's then logical to start with Acceptance Tests. After you've demonstrated visible outcomes in high level metrics that matter to the business (reduced/eliminated regression bug reports, reduced delivery time, etc.) you would have gained trust across the board - trust from the Business, your Enginnering Manager and from your team. It's because outcomes are much louder than words.
After you've had success with Acceptance Tests, you can then later move on to get buy-in for Component Tests, and lastly for Unit Tests.
[Part 2/3] Starting with Unit Tests is low-ROI, high-risk & high-resistance.
LOW VALUE: Unit Tests cover a very small scope. Imagine you have a 100 balls of a string and you need to walk across the balls. Unit Tests might test little parts of the balls, but you don't have assurance whether the balls are connected well together. So the Unit Tests might all pass, but you can't talk over the balls because perhaps the string is broken between two balls! So, you don't actually have assurance that you've satisfied the business requirements (unlike Acceptance Tests). This is also why, Unit Tests alone, are definitiely not enough.
HIGH COST: Unit Tests are higher cost to introduce (compared to Acceptance Tests) because firstly you have to make code unit testable (see Michael Feathers' book: "Working Effectively with Legacy Code") and you have to write many unit tests to attempt to cover a business functionality. It could take months/years to try to reach 100% Code Coverage & 100% Mutation Coverage.
HIGH RISK: In order to introduce Unit Tests, we need to change existing code to make it unit testable. Without the protection of Acceptance Tests, we can't know whether we broke functionality at the user-facing level! (even if all our Unit Tests are green)
HIGH RESISTANCE: To ensure that existing and new code is Unit Testable, developers have to change the way they write code. For example, they can't directly call I/O, they'd have to introduce abstractions via interfaces. You can then face major challenges with Senior Developers who want to continue doing things "their way" and who don't see the point "why should I change the way I write code just for the sake of unit tests".
[Part 1/3] Starting with Acceptance Tests is high-ROI, low-risk & low-resistance.
HIGH VALUE: We know that the test cases done by QA Engineers are valuable, so when we replace Manual QA Regression Tests by Acceptance Tests (and External System Contract Tests) we retain that business value. Unit Tests don't have that kind of business value.
LOW COST: Acceptance Tests are also low cost to introduce to Legacy Code (compared to Unit Tests) because we can leave the existing Big Ball of Mud as-is (no refactors/untangling needed!) and assumign we've setup our DSL & Drivers well, the cost to write an additional Acceptance Test should be low (similar cost as writing a human sentence).
LOW RISK: Since we aren't changing source code (we're staying with Big Ball of Mud), it means we're not risking Production going down. (Note: To be 100% precise, the only change that will be necessitated is ensuring that we have a configuration for connecting to External Systems, rather than hard-coded URLs; this is low-risk).
LOW RESISTANCE: Acceptance Tests don't force developers to change how they write their code. It's fine for developers to continue working with Big Ball of Mud! Acceptance Tests don't care what our System Architecture is like. We're not forcing the developers to change their architecture or coding practices, etc. Hence, we can expect zero/low resistance from developers when introducing Acceptance Tests.
Have you found that starting with acceptance tests makes it easier to get buy-in for unit tests later?
[Part 3/3] In summary, we've shown the following:
- Starting with Acceptance Tests is high-ROI, low-risk & low-resistance.
- Starting with Unit Tests is low-ROI, high-risk & high-resistance.
It's then logical to start with Acceptance Tests. After you've demonstrated visible outcomes in high level metrics that matter to the business (reduced/eliminated regression bug reports, reduced delivery time, etc.) you would have gained trust across the board - trust from the Business, your Enginnering Manager and from your team. It's because outcomes are much louder than words.
After you've had success with Acceptance Tests, you can then later move on to get buy-in for Component Tests, and lastly for Unit Tests.
[Part 2/3] Starting with Unit Tests is low-ROI, high-risk & high-resistance.
LOW VALUE: Unit Tests cover a very small scope. Imagine you have a 100 balls of a string and you need to walk across the balls. Unit Tests might test little parts of the balls, but you don't have assurance whether the balls are connected well together. So the Unit Tests might all pass, but you can't talk over the balls because perhaps the string is broken between two balls! So, you don't actually have assurance that you've satisfied the business requirements (unlike Acceptance Tests). This is also why, Unit Tests alone, are definitiely not enough.
HIGH COST: Unit Tests are higher cost to introduce (compared to Acceptance Tests) because firstly you have to make code unit testable (see Michael Feathers' book: "Working Effectively with Legacy Code") and you have to write many unit tests to attempt to cover a business functionality. It could take months/years to try to reach 100% Code Coverage & 100% Mutation Coverage.
HIGH RISK: In order to introduce Unit Tests, we need to change existing code to make it unit testable. Without the protection of Acceptance Tests, we can't know whether we broke functionality at the user-facing level! (even if all our Unit Tests are green)
HIGH RESISTANCE: To ensure that existing and new code is Unit Testable, developers have to change the way they write code. For example, they can't directly call I/O, they'd have to introduce abstractions via interfaces. You can then face major challenges with Senior Developers who want to continue doing things "their way" and who don't see the point "why should I change the way I write code just for the sake of unit tests".
[Part 1/3] Starting with Acceptance Tests is high-ROI, low-risk & low-resistance.
HIGH VALUE: We know that the test cases done by QA Engineers are valuable, so when we replace Manual QA Regression Tests by Acceptance Tests (and External System Contract Tests) we retain that business value. Unit Tests don't have that kind of business value.
LOW COST: Acceptance Tests are also low cost to introduce to Legacy Code (compared to Unit Tests) because we can leave the existing Big Ball of Mud as-is (no refactors/untangling needed!) and assumign we've setup our DSL & Drivers well, the cost to write an additional Acceptance Test should be low (similar cost as writing a human sentence).
LOW RISK: Since we aren't changing source code (we're staying with Big Ball of Mud), it means we're not risking Production going down. (Note: To be 100% precise, the only change that will be necessitated is ensuring that we have a configuration for connecting to External Systems, rather than hard-coded URLs; this is low-risk).
LOW RESISTANCE: Acceptance Tests don't force developers to change how they write their code. It's fine for developers to continue working with Big Ball of Mud! Acceptance Tests don't care what our System Architecture is like. We're not forcing the developers to change their architecture or coding practices, etc. Hence, we can expect zero/low resistance from developers when introducing Acceptance Tests.