[IOException]

#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 nr 2.

Bo generalnie feature i scenario mają być niezależne z definicji dobrych praktyk, tak?

[m.....t]

@IOException: Do takich testów powinieneś mieć jakoś z głową zseedowaną testową bazę danych - wtedy wszystkie problemy i wątpliwości powinny zniknąć.

[IOException]

@matiit: Niezła myśl.

[IOException]

@matiit: Ale ma pewne wady: Po każdym teście mam wgrywać nową bazę danych. Trochę bez sensu.

[m.....t]

@IOException: Możesz puszczeć każdy scenariusz w transakcji a potem rollback.

Najlepiej to jakbys mial testową bazę in_memory - wtedy możesz nawet wszystko po każdym teście robić od nowa - powinno być to dość wydajne.

[IOException]

@matiit: No nie wiem. Może przy testowaniu akceptacyjnym, lepiej usługami np po HTTP odtwarzać bazę aby być na świeżo, bo selecty z sql-a to masakra.

[m.....t]

@IOException: No a jakie testy piszesz w cucumberze? Przecież nie unit testy

[IOException]

@matiit: akceptacyjne i funkcjonalne

[m.....t]

@IOException: No i dla nich nie widze nic złego w wykonywaniu ich na bazie danych.

[IOException]

@matiit: Jak zwykle zależy. Jeżeli np żeby dodać książkę muszę dodać 5 innych rzeczy, np kategorie, usera jakiegoś, a aplikacja stoi na mikroserwisach, w których każda rzecz ma niezależną bazę, to pisanie skryptu wypełniającego wszystko i używanie tego za każdym razem, nie wydaje mi się słuszne, ale ciągle szukam, może to jedyne co warto zrobić.

[m.....t]

@IOException: No jasne, że tak. Ale mikroserwisy powinny być przetestowane w miarę możliwości w izolacji, a testy integracyjne nie muszą być z dugiej strony szybkie.