Reducing production bugs by 73% and speeding up deployment from 6 months to 1 month is very impressive Alessandro! Starting with Acceptance Tests is great as they provide the highest visible ROI.
It take us a lot of improvements, learnings, and also hard work.
At first, the idea of automating tests and building a CI/CD pipeline can feel overwhelming, even daunting. But you don’t need to start with a perfect or fully-fledged system.
We began with just a few tests and a couple of simple automation scripts. Even these small steps made a big difference: we identified some bugs before they ever reached production.
These early wins gave us (and our managers) the confidence and motivation to keep going. Each new test and every iteration on the pipeline brings us closer to a faster, more stable, and efficient process.
Starting with acceptance tests give us big results, we have now the confidence for improving out unit tests skills and improve our SW architecture
The takeaway? Start simple and watch the value grow. 🚀
Great advice! Yes, we should start small and focus on ROI.
For me, the beauty of starting with Acceptance Tests is that we get high ROI very fast with very low risk, and don't have to redo the whole architecture.
Then, when we demonstrate the results to managers (i.e. reduction in Production Bugs after introduction of Acceptance Tests), we then can get buy-in to apply automated tests at lower levels (which helps reduce feedback cycle).
I hope you're doing great! It's always a pleasure to read your articles about TDD. Honestly, I didn’t even know about acceptance tests before reading this one.
You mentioned starting software testing with acceptance tests and then moving on to lower-level tests like unit tests and integration tests. However, the acceptance tests don’t require implementing Clean Architecture or Hexagonal Architecture before performing them.
Does this mean that if we start a project and focus initially on acceptance tests, we don’t necessarily need to apply Clean or Hexagonal Architecture at the start? But eventually, we would still need to implement unit and integration tests later, right?
Thanks! Yes, manhy developers only heard of E2E Tests but not Acceptance Tests. We can think of Acceptance Tests same as E2E Tests just with the difference that External Systems are stubbed out (for Acceptance Tests) enabling us to test all Acceptance Criteria.
"You mentioned starting software testing with acceptance tests and then moving on to lower-level tests like unit tests and integration tests. However, the acceptance tests don’t require implementing Clean Architecture or Hexagonal Architecture before performing them."
Correct! Acceptance Tests does *not* impose any architectural style. It doesn't matte rif you have monolith or microservices. It doesn't matter if you have Big Ball of Mud. You certainly do *not* need HA, do *not* need CA.
"Does this mean that if we start a project and focus initially on acceptance tests, we don’t necessarily need to apply Clean or Hexagonal Architecture at the start?"
Correct! Indeed, in the case of Legacy Projects, the approach I advocate is to adopt the Acceptance Tests and leave the project as a Big Ball of Mud.
BUT if you're starting a greenfield project, then it's different - in that case I want to have tests at all relevant levels.
"Does this mean that if we start a project and focus initially on acceptance tests, we don’t necessarily need to apply Clean or Hexagonal Architecture at the start? But eventually, we would still need to implement unit and integration tests later, right?"
As part of my outline for Legacy Code transformation https://journal.optivem.com/p/tdd-in-legacy-code-outline we start with Acceptance Tests, then we go onto Component Tests... both of them do *not* need HA/CA, it's fine to have Big Ball of Mud.
Only at the end, when we go onto Unit Tests, then we require HA. (Though it does not mean we need CA, that's a different topic).
But should we apply HA/CA (and have unit tests)? Maybe yes, maybe no.
That's a bigger question, which I'll be answering later along in the series.
- If we have application-side business logic, then yes.
In the past, I used to put TDD, HA & CA all at the same level, same level of importance, and I used to think about TDD at the lowest level (the unit level).
My biggest switch that happened later is that I learned to prioritize:
Priority 1: (Must have for all projects): Pipeline, Acceptance Tests (& External System Contract Tests), Component Tests (& Contract Tests)
Priority 2: (Context dependent, I recommend for components with business logic at application-level): Hexagonal Architecture, Unit Tests (& Narrow Integration Tests)
Priority 3: (Context dependent, I recommend for components with business logic at application-level): Clean Architecture, DDD
This priority also happens to fit in well with organizations, to get the highest ROI earliest… and also least resistance from developers…
Initially when I started, I was very much influenced by Uncle Bob, very much Unit Tests & Clean Architecture, but later, through practice, I have a different model, and that’s why I’m writing the Optivem Journal.
Reducing production bugs by 73% and speeding up deployment from 6 months to 1 month is very impressive Alessandro! Starting with Acceptance Tests is great as they provide the highest visible ROI.
"Starting with Acceptance Tests is great as they provide the highest visible ROI." - that's the essence!
Many companies make the mistake of starting with Unit Tests, which is low ROI & high risk.
But starting with Acceptance Tests is high ROI & low risk.
Thank you for posting our story.
It take us a lot of improvements, learnings, and also hard work.
At first, the idea of automating tests and building a CI/CD pipeline can feel overwhelming, even daunting. But you don’t need to start with a perfect or fully-fledged system.
We began with just a few tests and a couple of simple automation scripts. Even these small steps made a big difference: we identified some bugs before they ever reached production.
These early wins gave us (and our managers) the confidence and motivation to keep going. Each new test and every iteration on the pipeline brings us closer to a faster, more stable, and efficient process.
Starting with acceptance tests give us big results, we have now the confidence for improving out unit tests skills and improve our SW architecture
The takeaway? Start simple and watch the value grow. 🚀
Great advice! Yes, we should start small and focus on ROI.
For me, the beauty of starting with Acceptance Tests is that we get high ROI very fast with very low risk, and don't have to redo the whole architecture.
Then, when we demonstrate the results to managers (i.e. reduction in Production Bugs after introduction of Acceptance Tests), we then can get buy-in to apply automated tests at lower levels (which helps reduce feedback cycle).
Hi Valentina,
I hope you're doing great! It's always a pleasure to read your articles about TDD. Honestly, I didn’t even know about acceptance tests before reading this one.
You mentioned starting software testing with acceptance tests and then moving on to lower-level tests like unit tests and integration tests. However, the acceptance tests don’t require implementing Clean Architecture or Hexagonal Architecture before performing them.
Does this mean that if we start a project and focus initially on acceptance tests, we don’t necessarily need to apply Clean or Hexagonal Architecture at the start? But eventually, we would still need to implement unit and integration tests later, right?
Hi Marc,
Thanks! Yes, manhy developers only heard of E2E Tests but not Acceptance Tests. We can think of Acceptance Tests same as E2E Tests just with the difference that External Systems are stubbed out (for Acceptance Tests) enabling us to test all Acceptance Criteria.
"You mentioned starting software testing with acceptance tests and then moving on to lower-level tests like unit tests and integration tests. However, the acceptance tests don’t require implementing Clean Architecture or Hexagonal Architecture before performing them."
Correct! Acceptance Tests does *not* impose any architectural style. It doesn't matte rif you have monolith or microservices. It doesn't matter if you have Big Ball of Mud. You certainly do *not* need HA, do *not* need CA.
"Does this mean that if we start a project and focus initially on acceptance tests, we don’t necessarily need to apply Clean or Hexagonal Architecture at the start?"
Correct! Indeed, in the case of Legacy Projects, the approach I advocate is to adopt the Acceptance Tests and leave the project as a Big Ball of Mud.
BUT if you're starting a greenfield project, then it's different - in that case I want to have tests at all relevant levels.
"Does this mean that if we start a project and focus initially on acceptance tests, we don’t necessarily need to apply Clean or Hexagonal Architecture at the start? But eventually, we would still need to implement unit and integration tests later, right?"
As part of my outline for Legacy Code transformation https://journal.optivem.com/p/tdd-in-legacy-code-outline we start with Acceptance Tests, then we go onto Component Tests... both of them do *not* need HA/CA, it's fine to have Big Ball of Mud.
Only at the end, when we go onto Unit Tests, then we require HA. (Though it does not mean we need CA, that's a different topic).
But should we apply HA/CA (and have unit tests)? Maybe yes, maybe no.
That's a bigger question, which I'll be answering later along in the series.
- If we have application-side business logic, then yes.
- Otherwise no.
Thanks,
Valentina
Waoh , thank you to take the time to give me the answer with the very clear explication ... Can't wait to read the next articles
In the past, I used to put TDD, HA & CA all at the same level, same level of importance, and I used to think about TDD at the lowest level (the unit level).
My biggest switch that happened later is that I learned to prioritize:
Priority 1: (Must have for all projects): Pipeline, Acceptance Tests (& External System Contract Tests), Component Tests (& Contract Tests)
Priority 2: (Context dependent, I recommend for components with business logic at application-level): Hexagonal Architecture, Unit Tests (& Narrow Integration Tests)
Priority 3: (Context dependent, I recommend for components with business logic at application-level): Clean Architecture, DDD
This priority also happens to fit in well with organizations, to get the highest ROI earliest… and also least resistance from developers…
Initially when I started, I was very much influenced by Uncle Bob, very much Unit Tests & Clean Architecture, but later, through practice, I have a different model, and that’s why I’m writing the Optivem Journal.