Rédaction efficace des autotests - tests sous-cutanés

L'essence du problème

• Les tests d'interface utilisateur sont lents. Il n'y a aucune échappatoire à cela. Ils peuvent être exécutés en parallèle, classés et exécutés un peu plus rapidement, mais ils resteront lents.
• Les tests d'interface utilisateur sont instables. En partie parce qu'ils sont lents. Et aussi parce que le navigateur Web et l'interface utilisateur n'ont pas été créés pour être contrôlés par un ordinateur (cette tendance est en train de changer, mais ce n'est pas le cas).
• UI- — . . ( , , , «» - , ).
• , , , UI- . . ID XPath . , «» - - . , , — - , .
• Quelqu'un dira que certaines fonctionnalités ne peuvent tout simplement pas être testées autrement. Je dirai que s'il existe des fonctionnalités qui ne peuvent être testées que par des tests d'interface utilisateur (à l'exception de la logique d'interface utilisateur elle-même), cela peut être un bon signe de problèmes architecturaux dans le produit.

Solution alternative

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

Nous avons perdu un peu de couverture, mais la vitesse des tests a augmenté 600 fois !!!

• Ajoutez un test d'interface utilisateur pour vérifier le code de colle, ou
• Si nous ne nous attendons pas à des changements fréquents du code de colle - laissez-le sans autotests, ou
• Si nous avons une sorte de test «manuel», il y a de fortes chances que le testeur remarque des problèmes avec le code de colle, ou
• Trouvez autre chose (même déploiement des Canaries)

Finalement

• Il n'est pas nécessaire d'écrire les autotests fonctionnels au niveau de l'interface utilisateur ou de l'API REST / SOAP. L'utilisation de «tests sous-cutanés» dans de nombreuses situations permettra de tester la même fonctionnalité avec une plus grande vitesse et stabilité.
• L'un des inconvénients de l'approche est une certaine perte de couverture.
• Une façon d'éviter de perdre la couverture est le « modèle de tests de fonctionnalités »
• Mais même avec la perte de couverture, l'augmentation de la vitesse et de la stabilité est significative.