7 Apr
2008
7 Apr
'08
12:27 p.m.
On Apr 7, 2008, at 11:35 AM, Sergiu Dumitriu wrote:
[snip]
While I
would like that very much, most of the time I find it almost
impossible to write (meaningful) tests. Sure, when dealing with user
interface features, we can write selenium tests to click here and
there
and see what happens, and when dealing with algorithmic stuff we can
write a unit test to see if an input gives the expected output. But
there are things that can't be tested that way, because they need a
running wiki. For example, how am I to test the attachments storage?
I haven't thought much about this specific use case but I can think of
several ideas:
1) Use DBUnit
2) Have automated tests that manipulates attachments through our UI
(create attachment, delete attachment, rollback doc version, etc)
3) We need to have several databases available (from xwiki.org, from
curriki for example) in different versions: 0.9.840, 1.0, 1.1, 1.2 and
1.3 and we need to run the test suite on all of them.
Right now we must do 2) for sure and someone need to work on 3). I
don't think we need 1).
But my mail was not really about this. It's a more general mail that
is asking everyone to be careful and whenever we make a change to
ensure that we have tests *as much as possible*, think whether it can
potentially break something, etc. To be more cautious. I've seen
several changes recently that were committed quickly without tests and
this is what I'd like to fight against.
Thanks
-Vincent
Mocking the storage is not the right thing, as that is
what I am
testing. Selenium tests are not suited for this, as I can't upload
files. I could abuse the selenium framework to write tests using
programming, mimicking the upload action, but that also requires too
much work and code duplication.
I hope that when we'll have everything as a component, testing will
be a
lot easier.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/