Moje doświadczenie z #tdd / #bdd na własnym projekcie pisanym czystokodami nowoczesnymi.

Wypisałem sobie 30 ogólnych epiców jakie ma robić moja apka. Biznesowe funkcjonalności.
W każdym z nich opisałem po 5-10 historyjek. W każdej z nich reguły akceptowalności w stylu: jest to, jeśli zrobię to to ma się zadziać to.

Jak duża ma być 1 funkcjonalność testowana? Kiedy jest zbyt ogólna a kiedy zbyt szczegółowa.

Zacząłem od bardzo szczegółowej. Wziąłem pojedyncze kryterium
aczutuse - Moje doświadczenie z #tdd / #bdd na własnym projekcie pisanym czystokodami...

źródło: peepokc-kcpeepo

Pobierz
Mam apkę w #java. Kiedy w IDE jako listę argumentów podaję null to oczywiście apka wywala NullPointerExeption. Jeśli jednak odpalić tę samą apkę w CMD i nie podać żadnych argumentów, to wtedy już rzucony zostaje ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0. Dlaczego tak się dzieje? Czy takie zachowanie w ogóle powinno zostać przetestowane? Jeśli tak to w jaki sposób?

public static void main(String[] args) {

String pat =
@69inch:

Dlaczego tak się dzieje


Bo w jednym przypadku robisz tablicę z jednym nullowm elementem a w drugim pustą tablicę.

Czy takie zachowanie w ogóle powinno zostać przetestowane? Jeśli tak to w jaki sposób?


No powinieneś przetestować. Testem jednostkowym np. Do przetwarzania listy argumentów powinieneś sobie jakąś klasę zrobić i tę klasę testujesz.
  • Odpowiedz
@69inch: nie da się. Testy jednostkowe testują wydzielony kawałek kodu, w twoim kodzie nie ma czegoś takiego. Musisz testować end-to-end
  • Odpowiedz
Proszę o wyjaśnienie czy dobrze rozumiem działanie i zastosowanie #cucumber Wiem, że głównie służy do automatyzacji testów ale powiedzmy, że chciałbym go użyć w testach manualnych. Czy każdy krok (Given, When, Then) musi służyć do zaimplementowania kodu, który faktycznie przeprowadza test, czy np Given może służyć do konfigurowania testów? Chodzi mi o taki fragment kodu jako przykład:

public class StepDefinition {
private PatternSearch ps;
private String txt;

@ Given("Input pattern is {string}")
via Wykop Mobilny (Android)
  • 2
@69inch: Twój When to powinien być kolejny Given (jako And). Potem When "Offset is calculated" z offset = ps.search(txt), i Then "Result offset equals {int}"
  • Odpowiedz
Ciekawe badanie. Wygląda na to, że osoby cierpiące na dysmorfofobię lepiej i dokładniej analizują swoją własną atrakcyjność fizyczną, na równi z artystami. Natomiast reszta społeczeństwa patrzy na siebie przez różowe okulary. Trochę jak z teorią depresyjnego realizmu. Oznacza to, że problem nie leży w nieadekwatnej ocenie własnej atrakcyjności, a nadmiernej odpowidzi emocjonalnej.

The role of aesthetic sensitivity in body dysmorphic disorder

#blackpill #przegryw #bdd
  • Odpowiedz
#bettercoding #programowanie #testowanieoprogramowania #testy #bdd #tdd

Cześć,
popełniłem wpis na temat konfiguracji Spock 2.0 + Maven w kilku wariantach: minimalnej, z customowymi nazwami klas testowych oraz integracja ze Spring'iem (SpringBoot).

Dla niewtajemniczonych: Spock to z frameworków testowych (podobnie jak JUnit). Jak wszystko - ma on swoje wady i zalety. Jednak w niektórych zastosowaniach (np. BDD, czy testy integracyjne) może okazać się dużo wygodniejszy np. od wspomnianych JUnit, chociażby ze względu na
pago - #bettercoding #programowanie #testowanieoprogramowania #testy #bdd #tdd 

Cz...

źródło: comment_1602842230txqUfeCa0uIpWxRJiG6cYk.jpg

Pobierz
Tyle się naczytałam o #tdd #bdd, trochę widziałam jak to działa w praktyce, ale że zespół dopiero zaczynał, to powiedzmy, że nie wyszło to książkowo ( ͡° ͜ʖ ͡°)

Pracuje ktoś w zespołach, w których podejście test-first rzeczywiście działa i się sprawdza - przyspiesza delivery, zmniejsza ilość błędów, pomaga wypuszczać lepszy soft? Od czego zależy powodzenie - dobrych wymagań, zrozumienia wśród managementu, umiejętności technicznych zespołu, czy czegoś
Najbardziej w tdd chodzi o to, żeby oddac się refleksji "jak zaprojektować klase / metode w klasie" zeby dalo rade to sensownie przetestowac.
Ktos moze powiedzieć, że to bez sensu, bo projektujemy kod pod kątem testu, ale w większości przypadków to jak wywołamy metodę w teście a wczesniej jak skonstruujemy obiekt da nam dużo wiedzy czy nie robimy jakiegoś grubego fackupu.

Ogólnie ksiązkowe podejście test-first sprawdza się w sumie dość rzadko, ale
  • Odpowiedz
@Snuffkin:
IMHO:
- tdd jest przereklamowane i przehypowane,
- testy integracyjne do testowania/monitorowania produkcji na okrągło są jedynymi koniecznymi testami,
- unit testy tylko do jak jest jakiś konkretny algorytm LUB test jest trywialny do napisania,
- naturalne jest, że unit testy się wyrzuca jak się zmienia api,
- niedoceniany temat to testy property-based – żyją w projekcie dłużej i jest znacznie większa szansa, że wyłapią pomyłkę na którą nikt nie
  • Odpowiedz
Cześć :)

Jak wiadomo podejście BDD jest podejściem biznesowym, nie rozpisujemy testowania aplikacji krok po kroku tzn.

When I fill name
And I fill last name...

tylko scenariusz ma wyglądać:

When i register in app

i to już pod tym krokiem znajduje się wypełnienie wszystkich danych. Mam jednak pewien problem, jak powinien zostać napisany test który sprawdza brak wypełnienia danych? Czy to ma być jeden globalny scenariusz sprawdzajacy brak wypełnienia wszystkich danych
@Dasad:
Ja preferuję inne podejście. Wyobraź sobie, że masz formularz użytkownika z polami 'name', 'location' i 'number'.
I teraz kolejno:
1. Korzystając z wyrażeń regularnych tworzysz sobie typy dla każdego pola:

@parse.with_pattern(r'\swith\sphone\snumber\s"\d+"')
def parse_phone_number(text):
2. Analogicznie tworzysz sobie typ danych, który będzie obsługiwał wyrazenie 'without phone number'
3. Rejestrujesz taki typ pod odpowiednią nazwą:

register_type( phone_number=parse_phone_number)
4. Używasz tego w stepie jako opcjonalny (!) parametr:

@when('I create new{admin:admin?} user with "{login}"
  • Odpowiedz
Potrzebuję porady. Nie mam doświadczenia w pisaniu BDD i dopiero zaczynam przygodę i wiem, że długa droga przede mną. Mam do napisania w Gherkinie TC, który będzie w przyszłości zautomatyzowany. Problem polega na tym, że nie jest to klikanie tylko w appce ale też muszę zmodyfikować URL, który dokonuje zmian w DB. Jednak do rzeczy, mam problem jak zdefiniować zmienną w URL, czy w ogóle można zdefiniować tą zmienną w Gherkinie, np
@gherkin_test: człowieku tego się nie da czytać ;)
Wklej te scenariusze może w całości bo jak każdy krok przeplatasz swoimi przemyśleniami to serio nie da się nic zrozumieć
  • Odpowiedz
@smaleckg: Zdecydowanie łatwiej będzie z konsoli. Od siebie polecam Mochę, bo ma od razu wbudowaną obsługę wiersza poleceń, do tego można dowolnie i łatwo dawać pluginy (np. istanbul do mierzenie pokrycia) i transpilery (babel, typescript) i to działa, no i przede wszystkim API Jasmine ssie, a w Mocha możesz sobie wybrać. Niemniej jeśli chcesz używać jasmine to instalujesz karmę (koryguję twój post, to jest runner, a nie miernik pokrycia), konfigurujesz, dodajesz
  • Odpowiedz
#programowanie #bdd #cucumber Jak napisać .feature i scenario: akcji:

1. Dodawanie elementu
2. Edytowanie elementu
3. Aktywacja elementu
4. Dezaktywacja elementu

Są to 4 niezależne ficzery?

Jeżeli chcę zrealizować edytowanie, to moim given lub background musi być założenie, że ten element już istnieje. I ten warunek powinienem zrealizować:
a) Jakoś wskazać, że to założenie realizuje inny feature nr 1, ale to zaburza niezależność.
b) Innymi sposobami zapełnić bazę tak, aby wykonać feature
Mirki, korzysta ktoś z Was z Behaviour Driven Development w komercyjnych projektach? Najlepiej w projektach kilku osobowych. Ostatnio miałem przyjemność prezentować to podejście kilkunastu osobom i wszyscy się zgodzili, że fajne, ale i tak na to w firmie nie ma czasu. Jak to jest u Was w firmach?

P.S. u mnie w firmie też nie ma czasu...

#programowanie #bdd #informatyka
@superlogin: Czyli moje przypuszczenia się potwierdzają, BDD się sprawdza tam, gdzie występuje interakcja pomiędzy komponentami. Mam tu na myśli warstwę logiki aplikacji (nie mylić z logiką biznesową), która odpowiada ze realizację przypadków użycia, gdzie BDD możemy traktować jako tak naprawdę testy akceptacyjne.

@archlinuxuser: w swoim założeniu historyjki użytkownika, pisane przez devów najczęściej w języku Gherkin opierają się na wymaganiach bądź scenariuszach dostarczonych przez klienta/analityka/konsultanta. Czyli tak naprawdę zadaniem programisty jest
markaron - @superlogin: Czyli moje przypuszczenia się potwierdzają, BDD się sprawdza ...

źródło: comment_uaVyxmAy3WOYvzLEhX6QGJwcxKjrWbCf.jpg

Pobierz
  • Odpowiedz