Dobry scenariusz testowy dla długiego procesu

W ramach eksperymentu chciałem przepisać produkt mojej poprzedniej firmy zgodnie z TDD. Głownie dlatego, że dosyć dobrze znam domenę i nie będę musiał tracić czasu na wymyślanie różnych rzeczy. Stwierdziłem, że zacznę od procesu składania zamówienia. Dla nowego klienta wygląda on mniej więcej tak:

1. Ktoś wchodzi na główną stronę.
2. Wpisuje kod pocztowy i klika szukaj.
3. Wybiera datę i godzinę oraz jakieś tam parametry zamówienia po czym klika dalej.
4. Podaje swoje dane: imię, nazwisko, hasło, adres i takie tam.
5. Wybiera metodę płatności i przechodzi na kolejną stronę.
6. Tutaj w zależności od metody płatności albo autoryzuje kartę, albo przechodzi na stronę pośrednika płatności.
7. "Thank you" page.

Wątpliwości, które mam:

1. Czy taki scenariusz nie będzie za długi? Jak przerobiłem to na Gherkina, to na pierwszy rzut oka wyglądało to trochę strasznie. Powinienem to jakoś podzielić?
2. Powyższy proces może się rozejść w wielu miejscach. Załóżmy, że chcę napisać dwa testy: płatność kartą, płatność przelewem. Czy w tym wypadku powinienem mieć dwa pełne scenariusze, które się różnią tylko krokiem 6, czy zrobić jakiś setup ("background") i zacząć scenariusz od kroku 5?
3. Jeżeli chciałbym sprawdzić, że klient może się zalogować (podczas kroku 4 klika, że ma konto), to czy powinienem również napisać cały test od początku do końca, czy powiedzmy tylko do tego momentu kiedy się loguje (1-4), a może tylko od tego momentu do końca (4-7) i zrobić setup używając "background" (sprawdzając, czy jak się zaloguje, to może domknąć zamówienie)?

1. Nie jest wg. mnie. Możesz ew. pokazać Gherkina.
2. Lepszy pomysł z Background i Given.
3. Staraj się nie testować 2 tych samych rzeczy, testy funkcjonalne zazwyczaj trwają długo bez żadnych powtórzeń i zniecierpliwieni programiści mogą niepotrzebnie coś popsuć zanim poznają wyniki testów :) Miej też na uwadze to, że w poprzednim kroku testujesz proces składania zamówienia a nie logowania, lepszym rozwiązaniem będzie (wg. mnie) osobno przetestować proces logowania - a w teście składania zamówienia użyć tylko Given I am logged in. Argumentem jest czas wykonania testów oraz to, że jak twój produkt zrezygnuje z procesu składania zamówienia to ktoś usunie też testy logowania nie zdając sobie z tego sprawy.

Dzięki za odp. @Markuz.
2. Czyli coś w stylu:

Scenario: User can make a booking using credit card
       Given I'm on the third step (ewentualnie można to przenieść do background, bo tutaj by było kilka testów dotyczących płatności)
       And I choose credit card payment
       When I fill credit card details... 
       Then...

Przy czym pierwszy "given" ustawiam wszystko tak, jak gdyby ktoś manualnie wykonał 1 - 4, tak?
3. Tutaj chodziło o to, że ktoś ma możliwość zalogowania się podczas procesu składania zamówienia i wszystko pójdzie jak trzeba (zamówienie zostanie do niego dopięte itd.). Ale z tego co zrozumiałem, to mogę zrobić tak samo jak w 2?

Scenario: User can log in during the booking process
       Given I'm on the third step
       And I log in as...
       And finish booking
       Then...

Tutaj "given" by robił to samo, co w pkt. 2, a "And finish booking" robiłby kroki 4 - 6 pod spodem. Co myślisz?

2. Tak, tylko z Background. Dobrze by było gdyby Given nie wykonywał kroków manualnych tylko otrzymywał aplikację w pożądanym stanie - wtedy testy będą szybsze. Podsumowując - kroki 1-4 jako osobny scenariusz "manualny" + osobne scenariusze dla konkretnych płatności z Given który otrzymuje aplikację w danym stanie.
3. Dobry pomysł.