Escribir autotests de manera efectiva - Pruebas subcutáneas

La esencia del problema

• Las pruebas de IU son lentas. No hay escapatoria de esto. Pueden ejecutarse en paralelo, archivarse y hacerse un poco más rápido, pero permanecerán lentos.
• Las pruebas de IU son inestables. En parte porque son lentos. Y también porque el navegador web y la interfaz de usuario no fueron creados para ser controlados por una computadora (esta tendencia está cambiando actualmente, pero no el hecho de que sea buena).
• UI- — . . ( , , , «» - , ).
• , , , UI- . . ID XPath . , «» - - . , , — - , .
• Alguien dirá que alguna funcionalidad simplemente no se puede probar de otra manera. Diré que si hay una funcionalidad que solo puede probarse mediante pruebas de interfaz de usuario (con la excepción de la lógica de la interfaz de usuario), esto puede ser una buena señal de problemas arquitectónicos en el producto.

Solución alternativa

public class LoginFormTest {

    SelenideMainPage sut = SelenideMainPage.INSTANCE;
    private static final String APPLICATION_URL = "http://localhost:4567/index";

    @BeforeClass
    public static void setUpClass() {
        final String[] args = {};
        Main.main(args);
        Configuration.browser = "firefox";
    }

    @Before
    public void setUp() {
        open(APPLICATION_URL);
    }

    @After
    public void tearDown() {
        close();
    }

    @Test
    public void shouldBeAbleToAddNewUser() {
        sut.setUserName("MyCoolNewUser");
        sut.clickSubmit();
        Assert.assertEquals("Status: user MyCoolNewUser was created", sut.getStatus());
        Assert.assertTrue(sut.getUsers().contains("Name: MyCoolNewUser"));
    }

    @Test
    public void shouldNotBeAbleToAddEmptyUseName() {
        final int numberOfUsersBeforeTheTest = sut.getUsers().size();
        sut.clickSubmit();
        Assert.assertEquals("Status: Login cannot be empty", sut.getStatus());
        Assert.assertEquals(numberOfUsersBeforeTheTest, sut.getUsers().size());
    }
}

public class UserApplication {

    private static IUserRepository repository = new InMemoryUserRepository();
    private static UserService service = new UserService(); {
        service.setUserRepository(repository);
    }

    public Map<String, Object> getUsersList() {
        return getUsersList("N/A");
    }

    public Map<String, Object> addUser(final String username) {
        final String status = service.addUser(username);
        final Map<String, Object> model = getUsersList(status);
        return model;
    }

    private Map<String, Object> getUsersList(String status) {
        final Map<String, Object> model = new HashMap<>();
        model.put("status", status);
        model.put("users", service.getUserInfoList());
        return model;
    }
}

public class UserApplicationTest {

    private UserApplication sut;

    @Before
    public void setUp() {
       sut = new UserApplication();
    }

    @Test
    public void shouldBeAbleToAddNewUser() {
        final Map<String, Object> myCoolNewUser = sut.addUser("MyCoolNewUser");
        Assert.assertEquals("user MyCoolNewUser was created", myCoolNewUser.get("status"));
        Assert.assertTrue(((List) myCoolNewUser.get("users")).contains("Name: MyCoolNewUser"));
    }

    @Test
    public void shouldNotBeAbleToAddEmptyUseName() {
        final Map<String, Object> usersBeforeTest = sut.getUsersList();
        final int numberOfUsersBeforeTheTest = ((List) usersBeforeTest.get("users")).size();
        final Map<String, Object> myCoolNewUser = sut.addUser("");
        Assert.assertEquals("Login cannot be empty", myCoolNewUser.get("status"));
        Assert.assertEquals(numberOfUsersBeforeTheTest, ((List) myCoolNewUser.get("users")).size());
    }
}

git checkout subctests

Perdimos un poco de cobertura, ¡pero la velocidad de las pruebas aumentó 600 veces!

• Agregue una prueba de IU para verificar el código de pegamento, o
• Si no esperamos cambios frecuentes en el código de pegamento, déjelo sin pruebas automáticas, o
• Si tenemos algún tipo de prueba "manual", existe una gran posibilidad de que el probador note problemas con el código de pegamento, o
• Proponer algo más (mismo despliegue de Canarias)

Finalmente

• No se requiere que las pruebas automáticas funcionales se escriban a nivel de UI o REST / SOAP API. El uso de "Pruebas subcutáneas" en muchas situaciones probará la misma funcionalidad con mayor velocidad y estabilidad.
• Una de las desventajas del enfoque es una cierta pérdida de cobertura.
• Una forma de evitar perder la cobertura es el " Modelo de pruebas de características "
• Pero incluso con la pérdida de cobertura, el aumento de la velocidad y la estabilidad es significativo.