--- Comment #16 from Tisza Gergő <> ---
(In reply to comment #14)
> > That step is not really functional anyway; even if the upload was not 
> > successful, the test will succeed, because the image hasn't been removed 
> > after
> > the previous test.
> Not true, the image is uploaded and a new revision is created, see:

What I mean is that if the new revision is not created, the assert will succeed
anyway, because the old revision has the same content. (True, the API returning
success but not uploading the file is a lot less likely then simply erroring
out, so the test would still catch most  upload problems.)

> I am willing to change this and create a new image every time the test
> is run, instead of generating a new version on every run. Still, I wouldn't
> blame the tests for this but the implementation.

Creating new images would mean that eventually a non-trivial fraction of
Commons images are test images. That would be even more disruptive. People who
patrol recent changes, list of new files etc. would probably complain.

> Disagree, having an automatic way of testing that important functionality
> is broken in production outweighs many costs. I don't see that many costs in
> this case. The image is 215 bytes, if many versions is an issue, then I can
> create a new image on every run.

I guess the main issue is that it will show up in the various change lists
(less often if you use get a bot flag for the test user). Having many revisions
might be a problem as well (for articles it used to be; the English Wikipedia
was borked several times by someone trying to delete a page with a long
history), but that should not be hard to prevent, as long as we do not forget
about it.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to