Yes, that’s the main purpose, ATDD helps us reach alignment, and that itself reduces the most expensive rework. This is because the biggest problem in software development is the problem of misalignmed requirements, it causes most expensive rework.
For MVP project, this is what I would most likely go with:
- Frontend & backend (monolithic backend, no microservices)
- I would for sure have System Level Tests (Acceptance Tests & External System Contract Tests, few E2E) and preferably doing it the ATDD way so that I can be sure my tests are actually valid... and in this way I would replace the need for Manual QA Testing. I'd find this useful for MVP projects because then it would mean that my software is in an always-ready releasesable state.
- I may or may not have Component Tests
- Unit Tests could be skipped, because at this point, I expect that the project is mainly CRUD with very low complexity (that's what I've observed in many MVP cases)
- Then after MVP goes live (e.g. 3 months), and that we've gotten funding, then we could start doing everything properly and retroactively add missing tests incrementally as we do new User Stories and then have to cover existing functionality with tests. It won't be too much work, because the project is still relatively small.
The above advice is what I see as relevant for most business applications. However, if it's an MVP in safety-critical or money-related applications, then even for MVP I might go the full way.
The MVP is a crypto currency app. I started with acceptance testing in component level. I don't have access to backend code base.
In the component level I got good results with acceptance tests when someone changed things related with the part of app where I have written tests. The tests broke.
But I got a seriously problem. For a MVP I believe I "wasted " so many time with testing so I guess I should not written test in some cases in my app, but I don't know when I need do it.
Acceptance Testing wasn’t possible, due to lack to access to backend
Component Testing for Frontend - that’s what you had done, and got good results when someone introduced regression bug on Frontend side
“But I got a seriously problem. For a MVP I believe I "wasted " so many time with testing so I guess I should not written test in some cases in my app, but I don't know when I need do it.“
Can you give an example of the kinds of tests where you wasted time? Was it the case that there were changing requirmeents, e.g. you wrote some tests based on requirements, then you had to throw away tests? Or was it the case that requirements were stable, but just that too much time went onto testing? Or was the problem something else?
"Can you give an example of the kinds of tests where you wasted time?"
I tests every module in my app (presentation/usecases/repositoies) with real implementation and mockout only de httpclient. So for presentations tests I don't wrote narrow integration tests and in repositories as well. So my app is full of component tests in every layer, with mock only in the last/external layer.
After I finish my task I come back to your post to try understand my mistake and I could see it was that I write fewer or none unit/narrow tests.
I believe it caused me went too much time onto testing.
Option 2: Component Tests & Contract Tests AND Unit Tests & Narrow Integration Tests
Here’s a thought experiment you could try to do, imagine you have a set of scenarios that your Component needs to satisfy, adn you want to ensure those scenarios are covered by tests. What would be the test count if you chose Option 1 vs Option 2, what would be the difference in maintenance cost? And to what extent does the answer differ if it’s a low-logic-complexity Component (e.g. mainly CRUD-like) versus high-logic-complexity Component (e.g. lots of business rules and/or calculations, and/or if-else, etc.)? If you do write up an example on day where you try to compare on a concrete example, feel free to let me know.
I’ve seen firsthand how ‘test-last’ leads to weeks of painful rework. Aligning early through executable specs (like ATDD) changes everything.
Yes, that’s the main purpose, ATDD helps us reach alignment, and that itself reduces the most expensive rework. This is because the biggest problem in software development is the problem of misalignmed requirements, it causes most expensive rework.
It's TDD always a good option for every project? It is a sincere question regarding about the use of TDD in a MVP project.
For MVP project, this is what I would most likely go with:
- Frontend & backend (monolithic backend, no microservices)
- I would for sure have System Level Tests (Acceptance Tests & External System Contract Tests, few E2E) and preferably doing it the ATDD way so that I can be sure my tests are actually valid... and in this way I would replace the need for Manual QA Testing. I'd find this useful for MVP projects because then it would mean that my software is in an always-ready releasesable state.
- I may or may not have Component Tests
- Unit Tests could be skipped, because at this point, I expect that the project is mainly CRUD with very low complexity (that's what I've observed in many MVP cases)
- Then after MVP goes live (e.g. 3 months), and that we've gotten funding, then we could start doing everything properly and retroactively add missing tests incrementally as we do new User Stories and then have to cover existing functionality with tests. It won't be too much work, because the project is still relatively small.
The above advice is what I see as relevant for most business applications. However, if it's an MVP in safety-critical or money-related applications, then even for MVP I might go the full way.
The MVP is a crypto currency app. I started with acceptance testing in component level. I don't have access to backend code base.
In the component level I got good results with acceptance tests when someone changed things related with the part of app where I have written tests. The tests broke.
But I got a seriously problem. For a MVP I believe I "wasted " so many time with testing so I guess I should not written test in some cases in my app, but I don't know when I need do it.
Thanks for the clarification, ok that means:
Acceptance Testing wasn’t possible, due to lack to access to backend
Component Testing for Frontend - that’s what you had done, and got good results when someone introduced regression bug on Frontend side
“But I got a seriously problem. For a MVP I believe I "wasted " so many time with testing so I guess I should not written test in some cases in my app, but I don't know when I need do it.“
Can you give an example of the kinds of tests where you wasted time? Was it the case that there were changing requirmeents, e.g. you wrote some tests based on requirements, then you had to throw away tests? Or was it the case that requirements were stable, but just that too much time went onto testing? Or was the problem something else?
"Can you give an example of the kinds of tests where you wasted time?"
I tests every module in my app (presentation/usecases/repositoies) with real implementation and mockout only de httpclient. So for presentations tests I don't wrote narrow integration tests and in repositories as well. So my app is full of component tests in every layer, with mock only in the last/external layer.
After I finish my task I come back to your post to try understand my mistake and I could see it was that I write fewer or none unit/narrow tests.
I believe it caused me went too much time onto testing.
Ok, based on your description, you were doing Component Testing only, not going down to Unit Testing (and Narrow Integration Testing).
In my article https://journal.optivem.com/p/modern-test-pyramid-unit-level in the section “Solution: Unit Testing”, I describe that for each Component, we can make a decision which way to go, for that COMPONENT:
Option 1: Component Tests & Contract Tests ONLY
Option 2: Component Tests & Contract Tests AND Unit Tests & Narrow Integration Tests
Here’s a thought experiment you could try to do, imagine you have a set of scenarios that your Component needs to satisfy, adn you want to ensure those scenarios are covered by tests. What would be the test count if you chose Option 1 vs Option 2, what would be the difference in maintenance cost? And to what extent does the answer differ if it’s a low-logic-complexity Component (e.g. mainly CRUD-like) versus high-logic-complexity Component (e.g. lots of business rules and/or calculations, and/or if-else, etc.)? If you do write up an example on day where you try to compare on a concrete example, feel free to let me know.