Deduce offending code from failed spec and coverage analysis
Problem to solve
As a developer trying to debug a failing test, I want some hints about what might have failed based on the changed files, so that I can quickly get my pipeline green again.
Intended users
User experience goal
The user should be able to use the UI of GitLab (Test Summary or JUnit report) to get a hint about what source code may be causing a test to fail so they can fix it.
Proposal
When a test fails, we know what code has changed in the MR, and what code the test covers from coverage analysis. Would it be valuable to intersect those to things and give the developer a hint as to which lines of code might be causing the error?
Further details
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
The benefit and likely buyer for this is the Individual Contributor or Developer. This feature should exist at the GitLab Core tier.
Is this a cross-stage feature?
As an MVC the solution to this problem is in existing Testing report areas but there may be an opportunity to add this information to the groupsource code feature set for tests that continually fail.