Skip to content

Latest commit

 

History

History
378 lines (242 loc) · 13.1 KB

readme-pending.adoc

File metadata and controls

378 lines (242 loc) · 13.1 KB

Symfony 4 & TDD

Branch Status

master

Build Status

Coverage Status

Codacy code quality

dev

Build Status

Coverage Status

Codacy code quality
Sommaire

1. Présentation

Ce repo est un terrain de jeu sur lequel je teste et valide des concepts de développement et de testing que je rencontre.

(WIP)

2. Cloner et installer le projet

(WIP)

2.1. Activer tous les alias du projet avec .bash_aliases

En chargeant le fichier des alias .bash_aliases, vous pouvez avoir un accès direct aux éléments de votre docker :

$ . .bash_aliases

$ php --version
PHP 7.2.22 (cli) (built: Sep  3 2019 08:57:25) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.22, Copyright (c) 1999-2018, by Zend Technologies

$ sf --version
Symfony 4.3.4 (env: dev, debug: true)

$ composer --version
Composer version 1.8.6 2019-06-11 15:03:05

3. Principes autour des tests automatiques

3.1. Pourquoi écrire des tests ?

3.1.1. Remplacer vos F5 par des tests automatiques

Un des objectifs des tests automatiques est de remplacer l’usage du F5 pour tester vos implémentations.

Important
 Les tests doivent être écrits pendant l’implémentation, et JAMAIS, JAMAIS, JAMAIS après.

Se poser la question "quoi et comment tester ?" doit se faire à chaud, durant les phases de réflexion de vos implémentations.

Les tests automatiques ne sont pas là que pour vérifier les valeurs de sortie de vos méthodes, ils orientent aussi les implémentations :

  1. Ils permettent d’appliquer plus tôt les principes SOLID

  2. Ils permettent de repérer plus tôt les défauts de design de l’implémentation

  3. Ils forcent à simplifier vos codes

  4. Ils fournissent de la documentation

Ecrire les tests après l’implémentation vous obligent à relancer une nouvelle phase de réflexion.

Cela vous demandera un nouvel effort pour retrouver les raisons de vos choix, et mécaniquement vous mettrez globalement plus de temps à écrire les tests : ces tests seront forcément plus difficiles à adapter à votre implémentation, et il y a de grandes chances que vous soyez obligés d’apporter de nouvelles modifications à vos codes déjà écrits.

Ainsi la règle est simple : plus d’une heure sans tests, c’est que c’est déjà trop tard !

3.2. Comment écrire des tests ?

(WIP)

3.3. Que faut-il tester ?

(WIP)

3.4. Comment exécuter les tests de ce projet ?

(WIP)

3.4.1. Avec le fichier Makefile :

$ make tests

3.4.2. Avec le fichier d’alias .bash_aliases :

$ . .bash_aliases
$ tests
$ t

Avec les alias vous pouvez ajouter des paramètres à la commande :

$ t path/to/my/fileTest.php

3.4.3. Dans PHPStorm

(WIP)

3.5. Pourquoi écrire des tests est-il aussi long ?

3.5.1. La gestion du temps dans le projet

(WIP)

3.5.2. Est-ce vraiment aussi long que cela en à l’air ?

(WIP)

4. Guide général pour le développement et la qualité de code

Qu’on se rassure, personne n’est parfait et n’importe quel développeur écrit du code "pas très clean" à un moment ou à un autre. Après tout, chaque développeur cherche à faire fonctionner ses applications…​ et parfois à n’importe quel prix !

Pourquoi tendre vers une qualité de code ? Pour éviter au maximum le code legacy.

Qu’est-ce qu’un code legacy ? Un code difficile à modifier et à maintenir, dont on a peu de connaissances fonctionnelles et techniques, dont on perd la compréhension.

Michael Feathers fournit une définition dans son ouvrage Working Effectively with Legacy Code : To me, legacy code is simply code without tests.

4.1. Bonnes pratiques de développement

4.1.1. Les principes STUPID

Les principes STUPID : reconnaître facilement les mauvaises pratiques pour mieux les corriger et les éviter dans les prochaines applications.

S

Singleton

Instance unique

T

Tight Coupling

Couplage fort

U

Untestability

Incapacité à tester le code

P

Premature Optimization

Optimisations prématurées

I

Indescriptive Naming

Nommage indéchiffrable

D

Duplication

Duplications

4.1.2. Les principes SOLID

Les principes SOLID : cinq bonnes pratiques orientées objet à appliquer au code afin d’en simplifier la maintenance, la testabilité et les évolutions futures.

S

Single Responsibility Principle

Principe de responsabilité unique : une classe, méthode ou fonction ne doit avoir qu’une seule responsabilité.

O

Open/Closed Principle

Principe ouvert / fermé : une classe doit être ouverte à l’extension, mais fermée à la modification.

L

Liskov Substitution Principle

Principe de substitution de Liskov : soit G, un sous-type de T, peut remplacer T sans modifier la cohérence du programme.

I

Interface Segregation Principle

Principe de ségrégation d’interfaces : utiliser plusieurs interfaces spécifiques pour chaque client qu’une seule interface générale

D

Dependency Inversion Principle

Principe d’inversion de dépendance : dépendre des abstractions et non des implémentations.

5. Configurer son PHPStorm (2018.2)

5.1. Les modules indispensables

5.1.1. Symfony Plugin

Après installation, activer le plugin pour le projet en cours :

  1. Aller dans File > Settings > Languages & Frameworks > PHP > Symfony

  2. Cliquer sur Enable Plugin for this Project (change need restart)

5.1.2. PHP Code Sniffer

PHP Code Sniffer est déjà installé dans ce projet. Pour activer l’analyse du code :

  1. Aller dans File > Settings > Languages & Frameworks > PHP > Code Sniffer

  2. Dans le bloc Development environment, choisir un interpréteur dans la liste Configuration

  3. Aller ensuite dans File > Settings > Editor > Inspections

  4. Cocher la case devant PHP > Quality tools > PHP Code Sniffer validation

5.1.3. Camel Case

Il suffit d’installer le plugin. Vous pourrez ensuite switcher entre les différents types avec le raccourci Sup + Alt + U

(WIP)

5.2. PHPUnit : suivre la couverture de code PHPStorm

5.2.2. Configurer Docker

Ajouter un nouveau daemon :

  1. Aller dans File > Settings > Build, Execution, Deployment > Docker

  2. Cliquer sur le bouton +

  3. Le nouvel interpréteur Docker s’ajoute à la liste : on peut voir Connect to Docker daemon with configuré sur Unix socket, avec le message Connection successful

Configurer Docker :

  1. Aller dans File > Settings > Build, Execution, Deployment > Docker > Tools

  2. Dans Docker Machine executable apparaît automatiquement docker, avec 19.03.2 à droite

  3. Dans Docker Compose executable apparaît automatiquement /usr/local/bin/docker-compose

Configurer l’interpréteur PHP :

  1. Aller dans File > Settings > Languages & Frameworks > PHP

  2. A droite de CLI Interpreter, cliquer sur le bouton …​

  3. Dans le nouveau panneau CLI Interpreters qui s’affiche, cliquer sur le bouton +

  4. Dans la fenêtre Select CLI Interpreter, choisir From Docker, Vagrant, VM, …​

  5. Dans le nouveau panneau Configure Remote PHP Interpreter, cliquer sur Docker. Des données s’affichent automatiquement :

    1. Server: Docker

    2. Image name: symfony-tdd_app:latest

    3. PHP interpreter path: php

  6. Dans le panneau Configure Remote PHP Interpreter, Cliquer sur le bouton OK

  7. Dans le panneau CLI Interpreters symfony-tdd_app:latest s’ajoute à la liste

  8. Cliquer sur le bouton OK

  9. Dans le panneau Settings apparaît automatiquement symfony-tdd_app:latest comme CLI interpreter et PHPStorm renseigne le Path mappings et le Docker container

  10. Cliquer sur le bouton OK pour valider le tout

5.2.3. Configurer PHPUnit

  1. Aller dans File > Settings > Languages & Frameworks > PHP > Test Frameworks

  2. Cliquer sur le bouton +, et choisir PHPUnit by Remote Interpreter

  3. Dans le panneau PHPUnit by Remote Interpreter, choisir symfony-tdd_app:latest

  4. Cliquer sur le bouton OK

  5. Interpreter: symfony-tdd_app:latest d’ajoute à la liste

  6. Renseigner dans Path to script: /opt/project/vendor/bin/simple-phpunit

  7. En cliquant sur le bouton de raffraichissement, apparaîtra juste en dessous PHPUnit version: 7.5.16

  8. Cocher Default configuration file et indiquer le chemin suivant : /opt/project/phpunit.xml.dist

  9. Cliquer sur le bouton OK pour valider le tout

5.2.4. Bien activer Prophesize

En lançant votre test, vous pourriez avoir l’erreur suivante :

Error : Class 'Prophecy\Prophet' not found

Dans la documentation (https://symfony.com/doc/current/components/phpunit_bridge.html#modified-phpunit-script) il est indiqué qu’il faut renseigner la variable d’environnement SYMFONY_PHPUNIT_REMOVE.

6. Sujets traités

6.1. Comment tester un classe abstraite ?

(WIP)

6.2. Comment créer et tester un validator ?

(WIP)

6.3. Comment créer et tester un customType ?

(WIP)

6.4. Ne plus injecter l’entityManager

(WIP)

7. Tips

7.1. Test fonctionnel : laisser PHPUnit intercepter les exceptions dans le terminal

$client->catchExceptions(false);

8. Ressources

8.3. Composants pour Symfony

  1. https://symfony.com/doc/3.4/components/dotenv.html

  2. A la decouverte du Workflow - Gregoire Pineau - PHP Tour Montpellier 2018 : https://youtu.be/9-jQf7CL7X4

8.4. Doctrine

  1. http://ocramius.github.io/doctrine-best-practices

  2. SymfonyLive Paris 2016 - André Tapia - Aller plus loin avec Doctrine2

  3. SymfonyLive Paris 2018 - Ne soyez plus l’esclave de Doctrine - Grégoire Paris & Maxime Veber + https://www.youtube.com/watch?v=KJ3uCPqNdPE