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

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

Ако решаването на проблеми е това, което търсите, наистина искате да можете да попитате, системата ми работи ли така, както искам, или по-конкретно, няколко въпроса като:

  • Могат ли хората да влизат?
  • Могат ли хората да излязат?
  • Могат ли хората да се запишат?
  • Работи ли интеграцията на лентите?
  • Моите крайни точки на API работят ли?
  • Могат ли хората да управляват обекти x, y и z?

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

Тестване от край до край

Има публикация в блог от инженер на Google (който е един от няколко хиляди инженери в Google) за това защо са се отдалечили от тестовете от край до край, ето как изглежда общото заключение за тестването от край до край

Мисля, че тази обща мъдрост изисква втори поглед въз основа на това откъде идва. Обикновено този тип мислене за „нестабилни тестове“ идва от големи екипи, където нещата се променят много бързо и където тестовете не се справят съвсем. Но ако сте соло разработчик или малък екип, нещата вероятно не се променят толкова бързо и вероятно е по-добре да имате набор от автоматизирани тестове от край до край, които се изпълняват за минути, вместо да се опитвате да тествате само новата си функция и да приемате тази промяна, която сте направили в този споделен обект или таблица, няма да засегне никоя друга функция.

Крайни тестове или напълно автоматизирани тестове на браузъри, използващи селен или нещо друго, наистина блестят в малки екипи и за независими разработчици. Наистина е лесно да напишете бърз тест от край до край и получавате много повече пробег от всеки ред от тези видове тестове в сравнение с няколкостотин теста на единица. Компромисът „отнема много време, за да ги изпълним“ (обикновено от порядъка на минути) срещу наносекунди, необходими за провеждане на няколко модулни теста, е компромис, аз и мисля, че много други независими хакери и малки екипи са готови да направят.

Заключение

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