On Fri, Feb 28, 2014 at 05:00:02PM +0100, Vadim Rutkovsky wrote:
Moreover, we can copy some of the test-data into homedir and then clean it up after tests complete. Continous do not have any problems with that but then running 'make check' on users local machine would break the user's homedir and some users might not like that at all.I think the application's tests should already contain sufficient test data (e.g. images). There are several examples of how this approachis being used now - Evince tests contain a set of PDFs and Evolution EWS tests contain required traces to mock Exchange server replies.
Unlike evince, gnome-documents and gnome-photos do not operate on random individual files. They look for local content in specific locations, and data from online accounts. We can implement a hidden option to override the location that is used for local content. We can then place our test data in this location and test against it. I do not think it makes sense to test the online account integration in these applications with things like uhttpmock. The individual libraries used to implement the Web APIs (like libgdata, libzapojit, grilo, etc.) can be unit tested with uhttpmock, but I would like to have some integration tests that work against the real server. Unit tests with uhttpmock is nice and cool, but if the thing does not work with the real server, what is the point? Once in a while the servers do change behaviour. Sometimes it is a transient bug in the server-side code, but sometimes it also exposes a bug in our code. We have hit such bugs with gnome-online-accounts, which would have been detected sooner if we could have tested against the real server. Happy hacking, Debarshi -- Wearing non-prescription glasses and embracing obscurity doesn't necessarily make you a hipster. -- Anonymous
Attachment:
pgp69EdIDz9HZ.pgp
Description: PGP signature