Fair points and fully agree with idea that when starting with something that I know will be quite a big piece of software with a lot of concerns - will opt in for unit level tests to help design separation of concerns and slowly build up the design or blueprint of my solution.
I think will need to come up with a series of examples and try writing different tests to see what works best in certain scenarios.
My main example for integration/e2e tests is Lambda because it usually should be small enough that having unit, integration and e2e tests seems like an overkill.
And often see a lot of tests in a codebase where behaviour is... tested too much? That’s why starting to question certain beliefs I hold.
Thanks for feedback, it’s something I want to write a little more about and need wider input/challenging opinions :)
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.
Fair points and fully agree with idea that when starting with something that I know will be quite a big piece of software with a lot of concerns - will opt in for unit level tests to help design separation of concerns and slowly build up the design or blueprint of my solution.
I think will need to come up with a series of examples and try writing different tests to see what works best in certain scenarios.
My main example for integration/e2e tests is Lambda because it usually should be small enough that having unit, integration and e2e tests seems like an overkill.
And often see a lot of tests in a codebase where behaviour is... tested too much? That’s why starting to question certain beliefs I hold.
Thanks for feedback, it’s something I want to write a little more about and need wider input/challenging opinions :)