There are four scrum teams under my line manager's supervision and we work together to build an android application. There is a team which builds foundational components that include common utilities used by the rest three feature teams.
My manager asks me to prevent my features from being accidentally or intentionally, if someone really does it, broken by other team members. The change may come from a team member within my scrum team or any other of the three teams. How can I do it without influencing my feature deliveries in the sprints?
Our unit tests are written to improve coverage only, they don't really signal a failure when a feature is broken.
By the way, I am developer with absolutely no managerial powers.
Accepted Answer
The best way is to make your tests validate behavior, not just increase coverage.
If a feature can be broken by another team's changes, add meaningful unit, integration, or UI tests that fail when the feature's expected behavior changes. Then run those tests in CI so regressions are caught before code is merged.
As a developer, you can't prevent people from changing code, but you can make breaking changes visible immediately through automated tests. Coverage metrics alone won't achieve that.
Shokhrukh Khusniddinov