Aktywne Wpisy
mirko_anonim +7
✨️ Obserwuj #mirkoanonim
Ja 32 lvl w tym roku. Moja #rozowypasek skończyła 28. Jesteśmy ze sobą od 2 lat. Mieliście już rozmowę o dzieciach? Jak przez to przebrnąć? Moja cały czas naciska, że ją już praca w banku męczy. Chce bachora, bo nie wie ile jej jeszcze placówka będzie działać, bo jej zegar biologiczny tyka, bo dziecko po 30 to będzie z downem itp. #!$%@? mnie to już, bo nie jestem na
Ja 32 lvl w tym roku. Moja #rozowypasek skończyła 28. Jesteśmy ze sobą od 2 lat. Mieliście już rozmowę o dzieciach? Jak przez to przebrnąć? Moja cały czas naciska, że ją już praca w banku męczy. Chce bachora, bo nie wie ile jej jeszcze placówka będzie działać, bo jej zegar biologiczny tyka, bo dziecko po 30 to będzie z downem itp. #!$%@? mnie to już, bo nie jestem na
Rozejść się?
- Tak 59.9% (848)
- Nie 7.5% (106)
- Zrobić bachora 18.2% (258)
- Zrobić bachora później i przetrwać gadanie 14.3% (203)
Teuvo +508
#wykop przywróćcie plusujących na wierzch na wersji webowej tak jak było wcześniej, biauek kogoś ty zatrudnił, cholerne gamonie to się w głowie nie mieści co wy robicie z tym portalem (╯°□°）╯︵ ┻━┻
źródło: ios_large_1450286011_image
Pobierz
Aktywne Znaleziska
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 czy globalny i inne scenariusze sprawdzające nie wypełnienie jednego z wymaganych pól np imienia? Jest to o tyle problematyczne, że byłoby sporo kroków do napisania różniących się praktycznie nie wypełnieniem tylko jednego pola
When I do not fill name
When I do not fill last name
Dodaje także tag programowanie ponieważ duża część programistów równieżzajmuje sie tymi zagadnieniami
#bdd #gherkin #testowanieoprogramowania #programowanie
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}"Examples:
|user|password|
|user1|password1|
| | |
|user2|password2|
W kodzie masz jedna metodę: iFillUserData(String user, String password)
A sterowanie parametrami zostawiasz biznesowi w pliku feature