Effektiv Autotests schreiben - Subkutane Tests

Das Wesentliche des Problems

• UI-Tests sind langsam. Es gibt kein Entrinnen davon. Sie können parallel ausgeführt, abgelegt und etwas schneller ausgeführt werden, bleiben jedoch langsam.
• UI-Tests sind instabil. Zum Teil, weil sie langsam sind. Und auch, weil der Webbrowser und die Benutzeroberfläche nicht für die Steuerung durch einen Computer erstellt wurden (dieser Trend ändert sich derzeit, aber nicht die Tatsache, dass dies gut ist).
• UI- — . . ( , , , «» - , ).
• , , , UI- . . ID XPath . , «» - - . , , — - , .
• Jemand wird sagen, dass einige Funktionen einfach nicht anders getestet werden können. Ich werde sagen, dass wenn es Funktionen gibt, die nur durch UI-Tests getestet werden können (mit Ausnahme der UI-Logik selbst), dies ein gutes Zeichen für Architekturprobleme im Produkt sein kann.

Alternative Lösung

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

Wir haben ein wenig Deckung verloren, aber die Geschwindigkeit der Tests hat sich 600-mal erhöht !!!

• Fügen Sie einen UI-Test hinzu, um den Klebercode zu überprüfen, oder
• Wenn wir keine häufigen Änderungen am Klebercode erwarten, lassen Sie ihn ohne Autotests oder
• Wenn wir eine Art „manuelles“ Testen haben, besteht eine große Wahrscheinlichkeit, dass der Tester Probleme mit dem Klebercode bemerkt, oder
• Lassen Sie sich etwas anderes einfallen (gleicher Einsatz auf den Kanaren)

Zusammenfassend

• Funktionale Autotests müssen nicht auf UI- oder REST / SOAP-API-Ebene geschrieben werden. Die Verwendung von „subkutanen Tests“ in vielen Situationen testet dieselbe Funktionalität mit höherer Geschwindigkeit und Stabilität.
• Einer der Nachteile des Ansatzes ist ein gewisser Deckungsverlust.
• Ein Weg, um einen Verlust der Abdeckung zu vermeiden, ist das „ Feature-Test-Modell “.
• Aber selbst mit dem Verlust der Abdeckung ist die Erhöhung der Geschwindigkeit und Stabilität signifikant.