Swagger permettant de decrire ce qui est consomme par le front et produit par notre API, nous l'avons utilise comme Spec. Theoriquement le front/back pouvaient s'accorder sur le comportement de l'API avant son implementation.
Pour avoir une visibilite sur l'implementation des modeles, le schema de la base a ete entierement decrit (dbdiagram):
Nous avons utilise rubocop pour gagner en lisibilite, coherence et qualite de code.
Le TDD faisant partie integrante de Rails, il m'etait difficile de passer a cote. Nous avons mis en place le processus suivant:
- decrire le comportement attendue de l'api (
swagger) - generer le squelette des
models/controllers/rspec - ecrire la factory puis les tests (
factory-bot/rspec/shoulda-matcher) - ecrire la migration, les contraintes du modele, les methodes du controller, le serializer et la route
- si besoin refactor
Un github workflow se declenchait sur chaque push sur master, si rubocop et les tests passaient la version etait deployee sur une instance d'Heroku en mode production.
J'ai pu monter en competence sur des sujets tres varies (Ruby, Rest, Websocket, Oauth2, JWT, MVC) et decouvrir un certain nombre des features de Rails (ActiveStorage, Caching, ActiveJob, ActionCable, Mailer, Devise, etc) mais l'interet principal de ce project restera pour moi la mise en place du TDD.
Je ne regrette pas d'avoir investi du temps dans sa mise en place et son "evangelisation", le projet pourrait etre maintenu et etendu facilement sur la duree sans creer de dette technique. Cependant il est probable que je me concentre sur des tests de comportement (ex spec/requests), tester l'implementation revient a poser un carcan qui n'encourage pas a refactor.
docker-compose up --build
http://localhost:3000/api-docs
docker exec -ti pong rspec
@kh42z, @Shankhara