Not so fast, if you have shared code that is breaking that'd be a perfect place to start introducing automated testing. In general automated UI testing is more work and false-flags than it's worth, but the exception is heavily reused code. That said, if you have code that is technically reused, but there are so many parameters that no use site is the same and changing the way one parameter gets interpreted causes issues with another, yes that'd be a good thing to fix up.
> When you have hundreds of variables and one of them throws DivisionByZero error or invalid data type, those are hard to catch
I will propose automated tests to my manager. Writing tests for shared code is a great idea. But I feel I should concentrate on integration tests as well (like flows spanning multiple lambdas)
Not so fast, if you have shared code that is breaking that'd be a perfect place to start introducing automated testing. In general automated UI testing is more work and false-flags than it's worth, but the exception is heavily reused code. That said, if you have code that is technically reused, but there are so many parameters that no use site is the same and changing the way one parameter gets interpreted causes issues with another, yes that'd be a good thing to fix up.
> When you have hundreds of variables and one of them throws DivisionByZero error or invalid data type, those are hard to catch
What makes those hard to catch?