Как да преработите и да откриете зависимости, когато правите BDD

Имам чувството, че може би прекалявате с това. Когато нещата изглеждат наистина объркващи, обикновено си напомням да направя крачка назад и да прегледам основите. Първо, искам да направя само минимума, необходим за удовлетворяване на изискване. Наистина не ме интересува дали ще има много зависимости в системата, за които все още не съм наясно, така че пиша тестовете си по възможно най-простия начин. Ако видя нужда от зависимост, ще хвърля макет и ще поддържам минималния интерфейс, необходим, за да позволи на теста ми да се изпълнява. Ако системата трябва да разшири или поддържа допълнителна зависимост по-късно, мога да разширя макета или дори да го заменя с нещо специфично за следващия тест, който напиша. Мога също да разширя тест или дори да напиша нов тест, за да отговоря на нови изисквания, когато ми станат известни и/или ясни.

Рефакторингът е просто изискан начин да кажа, че възнамерявам да променя нещо. Това може да е за оптимизиране или друго подобряване на дизайна или може да е, защото виждам необходимост от разкриване на нови интерфейси и зависимости. В такъв случай започвам, като напиша промяна в моите тестове или евентуално дори напиша нов тест, който може или не може да замени съществуващ тест. Когато това стане, отивам към моя код.

Отгоре надолу или отдолу нагоре, основите са по същество едни и същи. Въпросът наистина е кога зависимостите ще станат очевидни и след това определянето на стратегия за справяне с тях. Когато почувствате нужда да разбиете нещо, бих предложил много кратък пик. Оставете идеята да се оформи и я завъртете пред очите си, докато й задавате въпроси. Ако смятате, че е правилно да преследвате идеята, напишете тестове, за да се справите с проблемите, които вашият скок ви представя, след което кодирайте оттам.

Понякога усещам, че изпитвам желание да създам огромен набор от подигравки, за да се справя с всяка възможна зависимост, за която мога да се сетя, и всеки път, когато се връщам към повтарянето на „K.I.S.S.“, „Y.A.G.N.I.“ и „Накарай го да работи, тогава накарай го да работи по-добре“, отново и отново в главата ми, докато не получа съобщението, че не мога да си позволя да заседна, защото се опитвам да мисля твърде далеч напред.

Независимо дали използвате TDD, BDD или който и да е друг подход, поддържането на нещата прости и минимални е ключът към гарантирането, че няма да се заемете с твърде много наведнъж. Това е може би най-важното нещо, което трябва да запомните. Ако изглежда твърде трудно за визуализиране, тогава се запитайте дали имате „миризма на изисквания“, която предполага, че трябва да разбиете нещата малко по-подробно. Можете ли да разделите „историята“ на набор от по-малки истории, които обхващат цялото.

Знам, че не е задължително да съм отговорил директно на въпроса, който зададохте, но реших, че си струва да пиша по този начин, тъй като според моя опит зависимостите и преработките стават очевидни, когато задачите са малки и ограничени само до една функция или две, докато обратното се получава, когато задачите са твърде обобщени и оставени отворени за тълкуване.

С BDD вие не работите на ниво единица (т.е. един публичен метод от един публичен клас). Вие работите на системно ниво. Следователно ще искате да се подиграете с всичко извън границите на системата. Това означава, че системата за съхранение или външната система ще бъдат подигравани: файлове, бази данни, услуги и т.н.

Освен това ще искате да се уверите, че вашите спецификации се доказват многократно, така че като TDD, ще искате да се подиграете с всеки недетерминиран елемент. Това означава по-специално функциите часовник и Случаен, но може да означава и метеорологична услуга (която разбира се се припокрива със страничните елементи, които искате да осмиете) или нещо подобно.

Що се отнася до това как да ги откриете, виждам две възможности, които можете да използвате. Първо е да начертаете системна диаграма, която всъщност е кутия, която представя всичко във вашия SUT< /силен>. След това нарисувайте всичко, което знаете, че ще ви трябва, което попада в една от горните категории. На това трябва да се подиграваш.