¿Qué son los accesorios en la programación?

He oído hablar de este término muchas veces (en el contexto de la programación) pero no pude encontrar ninguna explicación de lo que significaba. ¿Algún buen artículo o explicación?

Creo que te refieres a los accesorios de prueba :

El propósito de un dispositivo de prueba es asegurar que haya un entorno bien conocido y fijo en el que se ejecuten las pruebas para que los resultados sean repetibles. Algunas personas llaman a esto el contexto de prueba.

Ejemplos de accesorios:

• Carga de una base de datos con un conjunto de datos específico y conocido
• Borrar un disco duro e instalar una instalación limpia conocida del sistema operativo
• Copiar un conjunto de archivos conocido específico
• Preparación de datos de entrada y configuración / creación de objetos falsos o simulados

(fuente: wikipedia, ver enlace arriba)

Aquí también hay algunos ejemplos prácticos de la documentación del marco 'Prueba de Google' .

Creo que las pruebas de unidad PHP tienen muy buena explicación de esto:

Una de las partes de las pruebas de escritura que lleva más tiempo es escribir el código para configurar el mundo en un estado conocido y luego devolverlo a su estado original cuando se complete la prueba. Este estado conocido se llama el accesorio de la prueba.

También los documentos de Yii describieron la prueba de accesorios en buena forma:

Las pruebas automatizadas deben ejecutarse muchas veces. Para garantizar que el proceso de prueba sea repetible, nos gustaría ejecutar las pruebas en algún estado conocido llamado dispositivo fijo. Por ejemplo, para probar la función de creación de publicaciones en una aplicación de blog, cada vez que ejecutamos las pruebas, las tablas que almacenan datos relevantes sobre publicaciones (por ejemplo, la tabla Publicar, la tabla Comentarios) deben restaurarse a un estado fijo.

Aquí el ejemplo simple de prueba de accesorios

<?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));
    }
}
?>

Esta prueba de unidad PHP tiene funciones con nombres setUpy tearDownque antes de ejecutar su prueba configura sus datos y al finalizar puede restaurarlos al estado inicial.

El término accesorio varía según el contexto, el lenguaje de programación o el marco.

1. Un estado conocido contra el cual se ejecuta una prueba

Una de las partes de las pruebas de escritura que lleva más tiempo es escribir el código para configurar el mundo en un estado conocido y luego devolverlo a su estado original cuando se complete la prueba. Este estado conocido se llama el accesorio de la prueba. Documentación de la Unidad PHP

Un dispositivo de prueba (también conocido como contexto de prueba) es el conjunto de condiciones previas o estados necesarios para ejecutar una prueba. El desarrollador debe configurar un buen estado conocido antes de las pruebas y volver al estado original después de las pruebas. Wikipedia (xUnit)

2. Un archivo que contiene datos de muestra

Fixtures es una palabra elegante para datos de muestra. Los accesorios le permiten llenar su base de datos de prueba con datos predefinidos antes de que se ejecuten sus pruebas. Los accesorios son independientes de la base de datos y están escritos en YAML. Hay un archivo por modelo. RubyOnRails.org

3. Un proceso que establece un estado requerido. 

Un dispositivo de prueba de software configura el sistema para el proceso de prueba al proporcionarle todo el código necesario para inicializarlo, cumpliendo así las condiciones previas que pueda haber. Un ejemplo podría ser cargar una base de datos con parámetros conocidos del sitio de un cliente antes de ejecutar su prueba. Wikipedia

Exactamente sobre ese tema, JUnit tiene un documento bien explicado. Aquí está el enlace!

La parte relacionada del artículo es:

Las pruebas deben ejecutarse en el contexto de un conjunto conocido de objetos. Este conjunto de objetos se llama accesorio de prueba. Cuando escribes pruebas, a menudo encontrarás que pasas más tiempo escribiendo el código para configurar el dispositivo que en los valores de prueba reales.

Hasta cierto punto, puede facilitar la escritura del código del dispositivo prestando especial atención a los constructores que escribe. Sin embargo, un ahorro mucho mayor proviene de compartir el código del dispositivo. A menudo, podrá usar el mismo dispositivo para varias pruebas diferentes. Cada caso enviará mensajes o parámetros ligeramente diferentes al dispositivo y verificará los diferentes resultados.

Cuando tienes un aparato común, esto es lo que haces:

Agregue un campo para cada parte del dispositivo Anote un método con @ org.junit. Antes e inicialice las variables en ese método. Anote un método con @ org.junit. Después de liberar los recursos permanentes que asignó en la configuración Por ejemplo, para escribir Varios casos de prueba que desean trabajar con diferentes combinaciones de 12 francos suizos, 14 francos suizos y 28 dólares estadounidenses, primero crean un accesorio:

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");
    }
}

En Xamarin.UITest se explica de la siguiente manera:

Por lo general, cada Xamarin.UITest se escribe como un método que se conoce como prueba. La clase que contiene la prueba se conoce como accesorio de prueba. El dispositivo de prueba contiene una sola prueba o una agrupación lógica de pruebas y es responsable de cualquier configuración para hacer que la prueba se ejecute y de cualquier limpieza que deba realizarse cuando finalice la prueba. Cada prueba debe seguir el patrón Arrange-Act-Assert:

• Organizar: la prueba configurará las condiciones e inicializará las cosas para que la prueba pueda llevarse a cabo.
• Actuar: la prueba interactuará con la aplicación, ingresará texto, presionará botones, etc.
• Afirmar: la prueba examina los resultados de las acciones realizadas en el paso Actuar para determinar la corrección. Por ejemplo, la aplicación puede verificar que se muestre un mensaje de error particular.

Enlace para el artículo original del extracto anterior

Y dentro del código Xamarin.UITest parece lo siguiente:

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.");
        }
    }
}

Espero que esto pueda ser útil para alguien que está buscando una mejor comprensión sobre los accesorios en la programación.