Надзвичайно коротка версія: менші тести, оскільки вони запускають менші частини системи, природно обмежують те, що можуть написати програмісти, і це створює можливість для більш різких (легше помітити / важче ігнорувати) зворотного зв’язку. Додам, що це не обов'язково призводить до кращого дизайну, але натомість створює можливість помітити ризики дизайну швидше.
По-перше, для уточнення, коли я кажу "мікротест", я маю на увазі "невеликий тест" і більше нічого. Я використовую цей термін, тому що я не маю на увазі "тест одиниці": я не хочу вплутуватися в дебати про те, що є "одиницею". Мені все одно (принаймні, не тут / зараз). Двоє людей, мабуть, легше домовляться про "малий", ніж на "одиницю", тому я поступово вирішив прийняти "мікротест" як новий стандартний термін для цієї ідеї.
Більш великі тести, тобто тести, які виконують більшу частину системи у своїй частині "дії", як правило, не критикують конструкцію так чітко і не настільки ж, як менші тести. Уявіть набір усіх баз коду, який міг би пройти задану групу тестів, це означає, що я міг би реорганізувати код, і він все-таки пройшов би ці тести. Для великих тестів цей набір більший; для менших тестів цей набір менший. Сказано інакше, менші тести більше обмежують дизайн, тому менша кількість конструкцій може змусити їх пройти. Таким чином мікротести можуть більше критикувати дизайн.
Я кажу "більш суворо", щоб створити образ друга, який прямо вам каже те, чого ви не хочете чути, але вам потрібно почути, і який кричить на вас, щоб передати терміновість таким чином, щоб інші люди не відчували себе комфортно робити. З іншого боку, інтегровані тести залишаються тихими і лише натякають на проблеми здебільшого, коли у вас більше немає часу і енергії для їх вирішення. Вбудовані тести дозволяють занадто легко підмітати проблеми дизайну під килим.
З більшими тестами (як інтегровані тести) програмісти, як правило, потрапляють у проблеми через неохайність: у них достатньо свободи писати заплутаний код, який якимось чином проходить тести, але їх розуміння цього коду швидко згасає, коли вони переходять до наступного завдання та інші мають зайві труднощі при читанні заплутаної конструкції. Тут криється ризик покластися на інтегровані тести. З меншими тестами (як мікротести) програмісти, як правило, потрапляють у проблеми через надмірну специфікацію: вони занадто обмежують тести, додаючи невідповідні деталі, як правило, копіюючи / вставляючи з попереднього тесту, і таким чином вони відносно швидко малюють себе в кут. Гарні новини: Мені набагато простіше і безпечніше вилучати сторонні деталі з тестів через кілька годин або днів після того, як я їх пишу, ніж я вважаю, що вони розривають заплутаний виробничий код від місяців до років після того, як я їх пишу. По мірі помилок надмірна конкретизація робить все більш очевидні пошкодження швидше, і попереджуючий програміст раніше бачить, що їм потрібно виправити речі. Я вважаю це сильним: я помічаю проблеми раніше і виправляю їх, перш ніж ці проблеми задушать нашу здатність додати функції.