[go: up one dir, main page]

Page MenuHomePhabricator

[EPIC] Encourage developers to increase code coverage
Closed, ResolvedPublic

Description

As a developer I want to develop on software that doesn't break in unexpected ways so that I can feel confident in the changes I am making to the codebase.

Possible parts of a solution
  1. Generate a code coverage report, i.e. increase/decrease in code coverage, in the pre-review hook and warn the developer if their patch decreases code coverage (or doesn't increase it, maybe)
  2. Tooling:
  3. Dashboards:

Related Objects

StatusSubtypeAssignedTask
Resolved Jhernandez
ResolvedNone
ResolvedLegoktm
DeclinedNone
DeclinedNone
DuplicateNone
ResolvedJdlrobson
DuplicateNone
Resolvedhashar
OpenNone
ResolvedLegoktm
DeclinedJdlrobson
DeclinedJdlrobson
DeclinedNone
ResolvedLegoktm
DeclinedNone
DeclinedNone
ResolvedSpikeovasileva
DeclinedNone
DeclinedNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
greg triaged this task as Medium priority.Jun 5 2015, 6:44 PM

Change 220025 had a related patch set uploaded (by Jdlrobson):
Add thresholds for QUnit coverage to ensure we don't get lazy

https://gerrit.wikimedia.org/r/220025

It seems a cheap way to do this would be to use the existing grunt qunit:cov command and then reject patches that push test coverage below a certain threshold (see patch above). This can be tweaked to not require any kind of storage and possibly plugged into Jenkins - thoughts @hashar ?

Change 220025 merged by jenkins-bot:
Add thresholds for QUnit coverage to ensure we don't get lazy

https://gerrit.wikimedia.org/r/220025

It seems a cheap way to do this would be to use the existing grunt qunit:cov command and then reject patches that push test coverage below a certain threshold (see patch above). This can be tweaked to not require any kind of storage and possibly plugged into Jenkins - thoughts @hashar ?

I'm not in favour of straight up rejection – you'll note that I said "warn the developer". I think that this patch jumps over a lot of discussion that we should be having as a team. We've only just started to have those discussions around the Q1 planning.

Should we use this task as the main tracking task across all projects? I made T111546: [EPIC] Add a voting test code coverage report to gate pipeline to track that, but the more I think about it/look at the blockers of this task already, I think *this* task is it.

Is it OK for me/RelEng to "take" ownership of this task (basically: removing the reading-team related projects, and have them create any reading-specific tasks as blockers of this)? I'll just merge that other task (T111546) into this one, if that's OK.

Better to merge / decline T111546: [EPIC] Add a voting test code coverage report to gate pipeline imho. Until we get a coverage build that is fast enough, I don't see it being added to gate (it takes 2 hours currently).

Is it OK for me/RelEng to "take" ownership of this task (basically: removing the reading-team related projects, and have them create any reading-specific tasks as blockers of this)? I'll just merge that other task (T111546) into this one, if that's OK.

Fine by me. There'll be reading-web-specific tasks that describe/track the work that we'll be doing so the beginning and end states will be almost the same, except that we'll have Release-Engineering-Team pushing us to do better too (!!!).

Change 526421 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/core@master] (wip) Provide command to adjust phpunit.xml for code coverage

https://gerrit.wikimedia.org/r/526421

Change 526421 merged by jenkins-bot:
[mediawiki/core@master] Provide command to adjust phpunit.xml for code coverage

https://gerrit.wikimedia.org/r/526421

kostajh subscribed.

Should we close this epic? Or assign some specific target that we want to reach?

hashar claimed this task.

I am claiming this one to have resolved years ago. The aim was to increase code coverage and we have plenty of coverage at https://doc.wikimedia.org/cover-extensions/ , a CI job which reports coverage improvement on patchset etc.

This was a program from ten years ago to improve testing practices at the foundation which resulted in many improvement. It has not been active in years as far as I know, but we still benefits from its improvements.

There are surely improvements to be made, but this task/goal/Epic has long been considered completed and decided to not pursue further.

hashar subscribed.