Full-stack developer (Symfony, Angular)
Взагалі вікі можна для початку, а потім вже заглиблюватися в літературу. Ось вам коротенько опис, мета якого більше надати ключові слова для пошуку.
Модульні, вони ж юніт тести, призначені для тестування окремих модулів / класів. Суть їх у тому, що ми тестуємо поведінку тільки одного класу за раз. Якщо клас посилається на інстанси інших класів - ми їх Мока. Тобто підсовує їм фейковий клас, який має той же інтерфейс, але всередині не реалізації методів, а перевірка, чи викликали метод, з яким аргументами, скільки разів викликали і т.д. Так само методи мока можуть повертати стаб (заглушки), якісь захардкоженние під якийсь кейс дані. Тобто якщо ми пишемо клас по роботі з базою даних, сокет-сервер і т.д. нам варто з'єднання з базою, сокети і т.д. обертати в класи, що б можна було потім підмінити на Моки це добро. Якщо у вас в юніт тестах йде реальна робота з файловою системою або що-небудь в цьому дусі, то це вже пахне інтеграційними тестами. Детальніше можна почитати в документації до phpunit. Так само є така методологія розробки як TDD, раджу почитати "Екстримальне програмування" Кента Бека в цьому ключі.
Інтеграційне тестування - тестування декількох модулів в зв'язці. Тобто ми тестуємо наш компонент або його самодостатній шматок в реальних умовах. Якщо цей компонент для роботи з файлами - дозволяємо йому доступ до файлів. Якщо база даних - то даємо реальне з'єднання з базою. А можемо щось і замокати. Це так би мовити, залежить від завдання. Скажімо звертання до сторонніх апішкам варто Мока і Стабія. Головна мета цих тестів, упевнитися що модулі разом працюють добре. Особливо важливо це коли модулі пишуть різні люди.
Функціональне тестування - це тестування всього програми в зборі. Якщо це REST API, то у нас через curl смикаються реальні методи, відправляються більш менш реальні запити і валідіруются відповіді. Якщо web-сторінка, то це UI тести з сіленіумом / phantom.js / zombi.js або, якщо нам не потрібно ще і js тестувати, просто curl + який віртуальний браузер на тому ж php. Взагалі по хорошому функціональні тести не дозволяють жодних моков і т.д. але знову ж якщо дуже хочеться то можна (знову ж звертання до сторонніх сервісів, контролю за якими у нас немає).
Але реалії такі, що UI тестами покривати проект не надто зручно. Поперше UI може змінюватися, а підтримувати їх так само потрібно. По друге це нудно. По-третє тести можуть просто падати. ось взяли і впали. І потім починається, так, тести знову впали. що там упало? А, не страшно, можна релізі. Так само на великих проектах UI тести відпрацьовують довго, дуже довго, деяких їх просто вночі ганяють. Толку від тестів при такому підході не дуже багато, бо розробнику варто знати про те що щось зламалося якомога швидше. А так він приходить, бачить що тести знову червоні, лагодить ці червоні тести, і запускає. чекає. проходить пів години наприклад, і десь в іншому місці відвалилося. Коротше самі розумієте.
Приймальне тестування - по суті ті ж функціональні тести, але подаються в контексті фіча-спеков. Якщо ви працювали коли-небудь з QA відділом, то можливо чули про такі штуки як acceptance criteria. Тобто це той чек лист, який повинен перевірити тестувальник що б упевнитися що все добре. На основі цього чек листа можна написати функціональні тести. Так само є інструменти на зразок Cucumber / Behat, які дозволяють писати специфікації у вигляді степ. В цьому випадку специфікації для цих інструментів можуть писати QA а ви просто імплементіте для них степи. Тобто зменшується прошарок між "acceptance criteria" і готовими до виконання тестів. Більш того, степ можна реюзать, комбінувати, маса степ є готових, вам же необхідно тільки надати Степи подготваллівающіе систему (завантаження / генерація фікстур і т.д.). Коротше лепота і зручно. Але повільніше інтеграційних, зате не такі жорсткі як функціональні, за рахунок цього їх простіше підтримувати. QA пишуть спеку, реалізуємо тести під цю спеку, пишемо код під тести, тести зелені - функціонал готовий.
Ну і є ще всякі терміни типу піраміда тестів і т.д. Мовляв краще багато юніт тестів, трохи менше інтеграційних і мало функціональних. Тоді тести виконуються швидше, а покривати все і вся функціональними тестами зазвичай перебір.
Ну і знову ж таки, є така річ як здоровий глузд. Деякі речі скажімо можна взагалі забити і не покривати тестами, деякі варто покрити. Деякі не повністю, деякі з якомога більшим покриттям. Скажімо тестувати UI (саме як виглядає, де який елемент) взагалі безглуздо. На це потрібно купа ресурсів. Хоча може і є проекти де це виправдано.
Коротше почитайте про TDD і ATDD (можна і BDD торкнутися, але тут не тільки від програміста залежить, менеджери, замовник або продукт-оунер теж повинні бути залучені, по суті цей підхід добре працює в рамках продукту якогось, на фрілансі і в аутсорс рідко можна зустріти). Continious Integration і Continious Delivery.
@StrangeAttractor 100% покриття коду тесамі означає що в рамках тест кейсів виконується кожен рядок коду, відпрацьовує кожна гілка if-ів і тд. Для більшості систем домогтися цього не особливо складно, просто можливо це зайве. Є речі які в принципі не можна покрити тестами на 100%.
Що до вашого випадку, швидше за все проблема з архітектурою. Якщо компонент складно покривати тестами, значить щось пішло не так. Ну або покривайте інтегрціоннимі.
@StrangeAttractor якщо чесно було б непогано просто побачити приблизний приклад, а то це "проміжне" це досить розпливчасто. Можете оформити? У будь-якому випадку все стороннє Мока і Стабія.