Testelka.pl

Testelka.pl - o technologiach w testowaniu oprogramowania

Strona główna > Kursy > Testy API w REST Assured > API w REST Assured 6. Zadanie: tworzenie i pobieranie obiektów

W tym zadaniu poćwiczymy to, co już poznaliśmy w poprzednich lekcjach, a będą to metody POST i GET. Obie z tych metod wykonamy w tym zadaniu wywołując poznane już metody w REST Assured.

Dokumentacja do sklepu

Po poprawnym postawieniu aplikacji dokumentację do niej znajdziesz pod localhost/fakestore/dokumentacja/. Tam też znajdziesz np. klucze potrzebne do uwierzytelnienia.

W idealnym świecie

W idealnym świecie ten test raczej rozbilibyśmy raczej na dwa różne testy. W jednym potwierdzalibyśmy, że obiekt się stworzył na podstawie tego, co dostalibyśmy w odpowiedzi na naszego POSTa. W drugim testowalibyśmy niezależnie pobieranie obiektów korzystając pewnie z zawsze takiej samej bazy danych. Piszę „raczej”, bo w przypadku odpowiedzi z POSTa nadal nie wiemy np. że dana wartość realnie zmieniła się w bazie. Nie dalibyśmy też prawdopodobnie kilku różnych asercji w środku zarówno po POST jak i po GET. Ponieważ realia naszej pracy nie zawsze osadzone są w idealnym świecie (a najczęściej nie są), może się zdarzyć, że w swojej pracy będziesz pisać podobne testy jak ten w dzisiejszym zadaniu. Natomiast jeżeli będzie możliwość testować tworzenie i pobieranie obiektów osobno, to polecam właśnie takie podejście.

Zadanie: metody POST i GET

Polecenie

Napisz test (tak, jeden test), w którym stworzysz nowy produkt o nazwie „Test Me 123”. Następnie dobierz się za pomocą API do tego stworzonego produktu i potwierdź po pierwsze, że możesz ten produkt pobrać, a po drugie, że ma prawidłową nazwę. Na koniec upewnij się jeszcze, że produkt ten występuje też na liście wszystkich produktów.

Rozwiązanie

Lepiej nie podglądać przed rozwiązaniem zadania ⚠️

Zastanówmy się jakie dotychczas poznane elementy musimy połączyć:

  1. tworzenie produktu,
  2. pobranie ID nowo utworzonego obiektu z response’a po stworzeniu tego produktu ,
  3. pobranie pojedynczego obiektu i potwierdzenie, że możemy go pobrać i że ma prawidłową nazwę (czy jakąkolwiek inną informację o tym produkcie, której się spodziewamy),
  4. pobranie listy produktów (pamiętając o parametrach) i sprawdzenie, czy gdzieś w nich pojawił się oczekiwany produkt.

Przypominam, że podstawowym sprawdzeniem odpowiedzi jest jego kod. Jeśli kod odpowiedzi nie jest taki, jakiego się spodziewamy, to najprawdopodobniej nie ma sensu sprawdzać dalej. Więc zawsze napisz asercję dla kodu odpowiedzi.

Ukryta treść

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc zobaczyć pełną lekcję.

Reader Interactions

Komentarze

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc komentować.

Komentarze

  1. Stanley92 napisał

    Witajcie,
    próbuję podać na wszelkie możliwe sposoby w body jsona nazwę zmiennej zadeklarowanej wyżej, jednak za każdym razem dostaję 400 zamiast 201. Czy da się jakoś "podciągnąć" zmienne pod jsona?

      private String products = "products";
    private String nameOfProduct = "Test Me 1231";

    @Test
    public void newProduct() {
        Response response = given()
                .port(80)
                .auth()
                .oauth(user, pass, "", "")
                .contentType("application/json")
                .body("{\"name\":" + nameOfProduct + "}")


                .when()
                .post(url + products);

        Assertions.assertEquals(201, response.statusCode());
        String createId = response.jsonPath().get("id").toString();
        Assertions.assertEquals(nameOfProduct, response.jsonPath().get("name"));
    Odpowiedz

  2. Mateusz Cesarz napisał

    Miałem ten sam error z integerem i stringiem we wcześniejszej lekcji i rozwiązałem go trochę inaczej: zamiast używać dodatkowej metody toString(), zamieniłem używanego przez Ciebie get() na getString() - i tu rodzi się moje pytanie: pod względem poprawności czy dobrych praktyk jest jakaś różnica?

    Odpowiedz