Teraz chcemy napisać test, który sprawdzi usuwanie elementu z listy. Jak pobrać referencję do przycisku: "Remove"? Można każdemu przycisku nadać unikalne id za pomocą data-testid.
Można też użyć funkcji within wystarczy, że przekażemy do niej pojedynczy element listy. Następnie za pomocą zapytania zdobyć referencję do przycisku.
Najpierw iterujemy po wszystkich elementach listy za pomocą getAllByRole. Tworzona jest tablica, która zawiera nazwę elementu i referencję do przycisku do usuwania zadania.
Przy każdej iteracji korzystamy z funkcji within. Przekazywany jest do niej pojedynczy element listy. Dzięki temu możesz napisać zapytanie: Pobierz mi przycisk o nazwie "Remove". Nie ważne, że na liście znajduje się więcej niż jeden taki przycisk o tej samej nazwie!
Zmienna, która jest computed property działa na takiej zasadzie, że nie przechowuje wartości, tylko jest ona obliczana przy próbie odczytu.
Domyślnie udostępnia getter do pobierania wartości. Opcjonalnie można przypisać także setter jeśli chcemy przypisywać zmiennej wartość.
Computed property można użyć w klasie, strukturze, enum lub nawet poza wymienionymi.
Najprościej można stworzyć computed property, w taki sposób:
structUser{
var firstName: String;
var lastName: String;
var fullName: String {
return firstName + " " + lastName
}
}
var user = User(firstName: "James", lastName: "Bond");
print(user.fullName) // James Bond
Zmienna fullName jest typu: computed property. W momencie odwołania się do niej w kodzie jej wartość jest ustalana "w locie".
O ile w Swift nie jest wymagane określanie typu danych zmiennej lub stałej, to w przypadku computed property taki typ musi zostać podany.
Getter
Pobieranie wartości dla computed property można zdefiniować jeszcze w inny sposób:
var fullName: String {
get {
firstName + " " + lastName
}
}
Tylko po co tak pisać skoro można obyć się bez get?
Istnieje możliwość dodania setter'a dla computed property.
Setter
Jeśli chcesz zmienić wartość computed property musisz określić mu setter. Bez tego próba przypisania wartości spowoduje błąd.
structHotel{
var rooms: Intvar allocated: Int = 0var roomsRemaining: Int {
get {
rooms - allocated
}
set {
rooms = allocated + newValue
}
}
}
var hotel = Hotel(rooms: 20)
print(hotel.roomsRemaining) // 20
hotel.allocated = 5print(hotel.roomsRemaining) // 15
hotel.roomsRemaining = 10print(hotel.rooms) // 15print(hotel.roomsRemaining) // 10
Kiedy tego użyć?
Jeśli tworzysz zmienną, która zależy od wartości innej zmiennej, jest to sygnał, że warto zadeklarować ją jako computed property.
Z drugiej strony należy uważać, bo możemy przesadzić. Wartość computed property jest obliczana za każdym razem, gdy pobierana jest z niej wartość. Więc jeśli umieścisz w takiej zmiennej kosztowne operacje, zapłacisz spadkiem wydajności aplikacji.
Pisanie testów dla funkcjonalności, które wykorzystują requesty może być irytujące. W zależności, jak taki test napiszesz.
Możesz mockować funkcje biblioteki, którą używasz do obsługi reqestów.
Albo przyjąć inne podejście: mockujesz tylko same requesty. To znaczy: jeśli w kodzie zostanie wywołany GET /api/user, ustalasz, że ma zwrócić konkretne dane i tyle!
Na pierwszy rzut oka oba podejścia mogą wydawać się podobne, ale tak nie jest.
W pierwszym podejściu skupiasz się niepotrzebnie na szczegółach: mockujesz konkretną bibliotekę i metodę. Co jeśli w przyszłości będziesz chciał zmienić bibliotekę do obsługi requestów? Po zmianie testy oczywiście się załamią.
Znacznie lepszym rozwiązaniem jest mockowanie samych requestów. Dzięki temu skupiasz się na testowaniu tego, co w rzeczywistości jest ważne: na testowaniu funkcjonalności, a nie szczegółach implementacji
Więc jak mockować requesty?
Jest kilka gotowych bibliotek. W tym wpisie opiszę, jak działa Nock.
Nock
Jest to prosta biblioteka, która pozwala w banalny sposób mockować requesty.