Que sont les projecteurs en programmation?

J'ai entendu parler de ce terme à plusieurs reprises (dans le contexte de la programmation) mais je n'ai trouvé aucune explication sur ce qu'il signifiait. De bons articles ou explications?

Je pense que vous faites référence aux appareils de test :

Le but d'un montage de test est de s'assurer qu'il existe un environnement bien connu et fixe dans lequel les tests sont exécutés afin que les résultats soient reproductibles. Certaines personnes appellent cela le contexte de test.

Exemples de luminaires:

• Chargement d'une base de données avec un ensemble de données spécifique et connu
• Effacement d'un disque dur et installation d'une installation de système d'exploitation propre connue
• Copie d'un ensemble connu de fichiers spécifique
• Préparation des données d'entrée et mise en place / création d'objets faux ou fictifs

(source: wikipedia, voir lien ci-dessus)

Voici également quelques exemples pratiques tirés de la documentation du framework «Google Test» .

Je pense que les tests unitaires PHP expliquent très bien ceci:

L'une des parties les plus chronophages de l'écriture de tests consiste à écrire le code pour configurer le monde dans un état connu, puis à le ramener à son état d'origine lorsque le test est terminé. Cet état connu est appelé la fixation du test.

Les documents Yii décrivaient également le test des appareils en bon état:

Les tests automatisés doivent être exécutés plusieurs fois. Pour nous assurer que le processus de test est reproductible, nous aimerions exécuter les tests dans un état connu appelé fixture. Par exemple, pour tester la fonctionnalité de création de publication dans une application de blog, chaque fois que nous exécutons les tests, les tables stockant les données pertinentes sur les publications (par exemple la table des publications, la table des commentaires) doivent être restaurées dans un état fixe.

Voici l'exemple simple de test de luminaires

<?php
use PHPUnit\Framework\TestCase;

class StackTest extends TestCase
{
    protected $stack;

    protected function setUp()
    {
        $this->stack = [];
    }

    protected function tearDown()
    {
        $this->stack = [];
    }

    public function testEmpty()
    {
        $this->assertTrue(empty($this->stack));
    }

    public function testPush()
    {
        array_push($this->stack, 'foo');
        $this->assertEquals('foo', $this->stack[count($this->stack)-1]);
        $this->assertFalse(empty($this->stack));
    }

    public function testPop()
    {
        array_push($this->stack, 'foo');
        $this->assertEquals('foo', array_pop($this->stack));
        $this->assertTrue(empty($this->stack));
    }
}
?>

Ce test unitaire PHP a des fonctions avec des noms setUpet tearDownqu'avant d'exécuter votre test, vous configurez vos données et une fois terminé, vous pouvez les restaurer à l'état initial.

Le terme fixture varie en fonction du contexte, du langage de programmation ou du cadre.

1. Un état connu sur lequel un test est en cours d’exécution

L'une des parties les plus chronophages de l'écriture de tests consiste à écrire le code pour configurer le monde dans un état connu, puis à le ramener à son état d'origine lorsque le test est terminé. Cet état connu est appelé la fixation du test. Documentation de l'unité PHP

Un montage de test (également appelé contexte de test) est l'ensemble des conditions préalables ou de l'état nécessaires pour exécuter un test. Le développeur doit configurer un bon état connu avant les tests et revenir à l'état d'origine après les tests. Wikipédia (xUnit)

2. Un fichier contenant des exemples de données

Fixtures est un mot sophistiqué pour les données d'échantillons. Les fixtures vous permettent de remplir votre base de données de test avec des données prédéfinies avant l'exécution de vos tests. Les luminaires sont indépendants de la base de données et écrits en YAML. Il y a un fichier par modèle. RubyOnRails.org

3. Un processus qui définit un état requis. 

Un dispositif de test logiciel configure le système pour le processus de test en lui fournissant tout le code nécessaire pour l'initialiser, satisfaisant ainsi toutes les conditions préalables. Un exemple pourrait être le chargement d'une base de données avec des paramètres connus à partir d'un site client avant d'exécuter votre test. Wikipédia

Exactement à ce sujet, JUnit a un doc bien expliqué. Voici le lien!

La partie connexe de l'article est:

Les tests doivent s'exécuter dans le contexte d'un ensemble d'objets connu. Cet ensemble d'objets est appelé un appareil de test. Lorsque vous écrivez des tests, vous constaterez souvent que vous passez plus de temps à écrire le code pour configurer l'appareil qu'à tester réellement les valeurs.

Dans une certaine mesure, vous pouvez faciliter l'écriture du code du fixture en prêtant une attention particulière aux constructeurs que vous écrivez. Cependant, des économies beaucoup plus importantes proviennent du partage du code de l'appareil. Souvent, vous pourrez utiliser le même appareil pour plusieurs tests différents. Chaque cas enverra des messages ou des paramètres légèrement différents à l'appareil et vérifiera des résultats différents.

Lorsque vous avez un appareil commun, voici ce que vous faites:

Ajouter un champ pour chaque partie de l'appareil Annoter une méthode avec @ org.junit.Before et initialiser les variables de cette méthode Annoter une méthode avec @ org.junit.After pour libérer toutes les ressources permanentes que vous avez allouées dans setUp Par exemple, pour écrire plusieurs cas de test qui veulent travailler avec différentes combinaisons de 12 francs suisses, 14 francs suisses et 28 dollars américains, créent d'abord un appareil:

public class MoneyTest {
    private Money f12CHF;
    private Money f14CHF;
    private Money f28USD;

    @Before public void setUp() {
    f12CHF= new Money(12, "CHF");
    f14CHF= new Money(14, "CHF");
    f28USD= new Money(28, "USD");
    }
}

Dans Xamarin.UITest, il est expliqué comme suit:

En règle générale, chaque Xamarin.UITest est écrit en tant que méthode appelée test. La classe qui contient le test est appelée appareil de test. Le montage de test contient soit un seul test, soit un regroupement logique de tests et est responsable de toute configuration pour exécuter le test et de tout nettoyage qui doit être effectué une fois le test terminé. Chaque test doit suivre le modèle Arrange-Act-Assert:

• Organiser - Le test configurera les conditions et initialisera les choses afin que le test puisse être exécuté.
• Agir - Le test interagira avec l'application, saisira du texte, poussera des boutons, etc.
• Assert - Le test examine les résultats des actions effectuées dans l'étape Act pour déterminer l'exactitude. Par exemple, l'application peut vérifier qu'un message d'erreur particulier est affiché.

Lien vers l'article original de l'extrait ci-dessus

Et dans le code Xamarin.UITest, cela ressemble à ceci:

using System;
using System.IO;
using System.Linq;
using NUnit.Framework;
using Xamarin.UITest;
using Xamarin.UITest.Queries;

namespace xamarin_stembureau_poc_tests
{
    [TestFixture(Platform.Android)]
    [TestFixture(Platform.iOS)]
    public class TestLaunchScreen
    {
        IApp app;
        Platform platform;

        public Tests(Platform platform)
        {
            this.platform = platform;
        }

        [SetUp]
        public void BeforeEachTest()
        {
            app = AppInitializer.StartApp(platform);
        }

        [Test]
        public void AppLaunches()
        {
            app.Screenshot("First screen.");
        }

        [Test]
        public void LaunchScreenAnimationWorks()
        {
            app.Screenshot("Launch screen animation works.");
        }
    }
}

J'espère que cela pourrait être utile à quelqu'un qui cherche à mieux comprendre les appareils dans la programmation.