Hej, dziś postaram się w pigułce wyjaśnić czym są TDD oraz BDD, a także wyszczególnić różnice pomiędzy nimi. Wiem – może zagadnienie nie jest giga praktyczne, raczej teoretyczne, rekrutacyjne. Koniec końców testowanie JS jest istotne, a więc powinniśmy pi razy drzwi wiedzieć z czym wiążą się TDD oraz BDD.
BDD = behaviour driven development
TDD – Test Driven Development
- Jak sama nazwa wskazuje – developerka oparta jest na testach, implementacyjnych zagwozdkach kodu.
- Flow pracy wygląda następująco:
- piszemy test
- piszemy kod, który powinien być poprawny wg testów
- testujemy kod
- poprawiamy bugi
- Każdy nowy kod powinien być od początku swojego istnienia pokryty testami (hue hue)
- Niestety TDD często prowadzi do testowania API (a nie realnego scenariusza), a to z kolei kończy się ciężkimi w utrzymaniu testami, nieintuicyjnymi, niesemantycznymi metodami o dziwnych nazwach, a koniec końców testami, które mówią co najwyżej, że aplikacja robi to, co robi.
BDD – Behaviour Driven Development
- Jak sama nazwa wskazuje – developerka oparta jest na realnych scenariuszach używania aplikacji.
- Zapominamy o implementacji funkcjonalności, skupiamy się samych funkcjonalnościach – porządanych i nieporządanych, na tym, co użytkownik może zrobić, gdzie kliknąć, itd.
- Flow pracy j.w.:
- piszemy test
- piszemy kod, który powinien być poprawny wg testów
- testujemy kod
- poprawiamy bugi
- Każdy nowy kod powinien być od początku swojego istnienia pokryty testami (hue hue).
- Ponoć stworzone po to, aby wyeliminować problemy testowania za pomocą TDD.
PORÓWNANIE
Różnice między TDD a BDD?
Na pierwszy rzut oka tylko składnia. Może też styl opisu speców – BDD jest bardziej opisowy. I doczytałam się, że to jest właśnie TO. Ten opisowy charakter, możliwość czytania opisów jako normalnych, pełnych zdań, sprawia, że lepiej rozumiemy naturę testów, przypadki testowe, a co za tym idzie – lepiej piszemy testy. Przynajmniej w teorii.
Poza tym BDD skupia się na „ficzerach”, funkcjonalnościach, z kolei TDD na wynikach testów. W TDD bierzemy funkcję i sprawdzamy, czy dla konkretnych danych wejściowych uzyskujemy odpowiedni wynik. Input-output. Nic więcej. BDD wydaje się być przy tym bardziej życiowy. Testy BDD są pisane z punktu widzenia użytkownika systemu, pomagają lepiej zaprojektować aplikację. Nie tylko testować.
Na przykład: są różne metody sortowania (bąbelkowe, szybkie..). Z perspektywy BDD, należy wykonać jeden test sprawdzający, że dana lista została prawidłowo posortowana. I tyle. Z perspektywy TDD, testy powinny sprawdzić nie tylko wynik sortowania, ale też poprawność zastosowanego algorytmu.
TDD czy BDD?
Cóż… Internety krzyczą, że TDD już umarło, z kolei BDD jest super i tego właśnie należy używać. Niektórzy mówią, że BDD to dobrze zrobione TDD ? Jednak nie chcę tu wywoływać wilka z lasu, nie jestem specjalistką. Ja tylko podaję zbiór informacji, które wygrzebałam z sieci o testowaniu kodu, według najbardziej popularnego podejścia.
Dokopałam się do chyba logicznej opinii, że wybór pomiędzy nimi zależy tak naprawdę od wielu czynników (używanych narzędzi, frameworków, języka programowania, zespołu programistów, wymagań klientów…). Inna opinia, jaką znalazłam mówi, żeby testować na oba sposoby! Ilu programistów, trzy razy tyle opinii.
