Suite à mon exploration de Google App Engine Patch (AEP), j’ai regardé de plus près les framework de tests. Le constat global est que l’on nage un peu dans le monde de l’Open Source: plétorde de possibilités, mais au final aucune ne matchant parfaitement mes besoins (j’exagère délibérément mais cela donne ce sentiment).
Le premier fautif est certainement Google lui même. Je suis d’accord avec Michelschr quand il dit que Google devrait fournir les outils (ou API) pour que les développeurs suivent les bonnes pratiques de développement. Cela m’étonne effectivement d’autant plus que Google a une excellente équipe dédiée aux pratiques du test.
Au final, on tombe sur une myriade de framework adressant dans aspects différent du test. Il est alors très dur de trouver celui qui convient, et souvent il ne fonctionne pas parfaitement bien du fait que par exemple il est adapté à Django, mais pas à AEP.
J’ai donc réduit mes recherches sur les tests unitaire (et non pas fonctionnel). AEP étant basé sur Django, qui est un framework MVC, il me semblait évident de trouver quelque chose d’adapter a ce genre de tests. Ma première surprise fut de constater que Gaeunit exécute les tests dans l’environnement Google App Engine (GAE)…et non pas dans le SDK. C’est a mon avis utile, mais plutôt pour des “smoke” tests ou tests de prod. J’ai donc écarté cette option.
J’ai regardé ensuite les possibilités du coté de Django. Je ne suis vraiment pas fan du test-per-class où l’on associe systématiquement une classe de test par classe de code. Doctest, lui intègre les tests dans chaque fonction. Je préfère de loin placer les tests au niveau de la fonctionnalité ou du “comportement” (BDD) qui repose moins sur le refactoring qui est toujours plus délicat sur les langages dynamiques.
Autre possibilité: unittest de Django. Il est certainement possible de faire tourner ces tests dans le SDK AEP, mais cela ne fonctionne pas out-of-the-box. Django est en effet patché au vol par AEP et cela complique la mise en place de ces tests.
J’ai donc recherché quelque chose de simple, avec comme seuls pré-requis: ne fait pas intervenir d’url mais permet de “rendre” les template, et permet de mettre les tests dans un répertoire séparé des sources. J’ai au final utilisé gaetestbed (qui est très light), avec Mock, plus quelques classes permettant de créer des “fausses” requêtes HTTP POST et GET. J’utilise nose pour lancer mes tests.
Au final, j’arrive a tester l’ensemble MVC en total isolation (pas de browser, authentification mockée…etc). Il est claire que cette solution est restreinte à ce type de tests…mais pour l’instant je n’ai besoin que de cela. A noter que le DataStoreTestCase ne permet que de savoir le nombre de requetes exécuté…ce qui est clairement très insuffisant. En regardant de plus près, c’est GAE qui n’expose quasiment rien…je vais certainement devoir mocké (en stub) pour améliorer cela…a voire.