Это всё очень даже логично. Но баги то другие. Т.е. я понимаю прекрасно для много людей, постоянно что-то ломается и т.д. Но в моём личном восприятии команда QA с ручным тестированием, повышеной адекватностью ( например в состоянии посмотреть на гит хаб что бы увидить какие файлы поменялись что бы знать куда усилия направлять ) работает намного эффективнее. Стоит ли ивестировать в автоматизацию которя может стоить + 20-50% проекта или в QA или и туда и туда - тут пусть каждый решает сам. Я писал тесты 10 лет а теперь считаю что это была ошибка и лучше бы злого qa взять.crypto5 wrote:Юнит тесты слабо эфективны для нахождения хитрых багов, они больше что бы задекларировать ожидаемое поведение вашей системы, и сигнализировать если кто-то что-то поломает когда будет добавлять фичу или рефакторить. Когда у вас будет значительно больше 5-и программистов, большая часть колектива сменится по пару раз, будет куча старого кода, а полное регрессивное тестирование на каждый чих будет занимать 4 недели и стоить много денег, покрытие тестами очень здорово окупиться как в плане продуктивности разработки так и в плане стабильности продукта.stenking wrote:Точно! Нужно написать тест который проверяет или нет дубликатов. А потом прочитать получше и увидеть что Патрол <> Полис и подумать а нафига я сейчас убил 2 часаИнтеррапт wrote:Мухаха. И "Private Patrol Officer" два раза повторяется. Вот тебе, стенкинг, твои филипинские тестерыАццкоМото wrote:Убрать лишнее двоеточие, напримерstenking wrote: Что тут можно сделать?
Нy и в нормальном процессе вам не надо писать 2 часа тест. Инфраструктура тестирования должна развиваться вместе с кодом, и вам достаточно вбить в тесте что-то initDb().addKeyword('hello').addKeyword('ehlo') что бы заинициализировалась база с кучей около продакшн данных + ваши данные необходимые для теста.
Но всё это спефифично для 1) веб эппов 2) команд до 10 человек 3) стартапов до 10М пользователей.
