--- Comment #14 from ---
Thanx for your comments, below my replies:

> I do not think tests that create data entries should be run on the real wiki.

How do we test that the functionality is working in the real wiki then? In my
experience it is OK to run integration tests and end-to-end tests against
production environments.

> And at the very least you should document what you are doing on that user's
talk page.

This I can do, ;-).

> 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:

  In fact, that's why I had to add ""ignorewarnings=true" in the second API
without this, the upload operation is not even tried because the file already

> Also, automated tests tend to break things in unexpected
ways, because they do stuff many more times than real users would.

  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.

> Given the subtle differences between live and beta, running the full smoke 
> test
on live would be useful... but the costs probably outweigh the benefits.

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.

> note that Commons has a Category "Test images" which this test should use if 
> it
loads a real file.

I manually added this category to the wiki page but it can be done as part of
the script.

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