Зачем смотреть весь костюм? Ведь можно оценить по частям. К пуговицам претензии есть?

Весь костюм смотрится на других этапах тестирования.

Значит, ваши теории "делай хорошо и не делай плохо" не работают.

откуда данный вывод? Люди просто не имели понятия о каких то теориях и писали как умели.

Но особого смысла в подобных дискуссиях не вижу. Человека не перетянуть из одной религии в другую насильно.

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

Не стройте на века. Бесполезно и неблагодарно.

совершенно правильно, последнее землетрясение в Турции подтверждает именно эту теорию.

Японцы полнейшие идиоты, зачем инвестировать столько времени и денег.

Следил за одним проектом в сети.

Я бы предложил сделать анализ успешных проектов...

Правильный вызов логина на объекте юзер - прерогатива объекта юзер. Вот в юните для него пусть и тестируется. А так вы в любом месте вызова логина будете этот вызов тестировать? В пяти разных местах будет - в пяти местах будете тестировать, хотя вызов зависит лишь от объекта юзер, который находится в одном месте.

Сначала надо ответить на вопрос "что мы тестируем". Если мы тестируем функцию Login, то unit under test - объект юзер. В данном случае unit under test - функция Foo и правильно ли работает объект User не имеет никакого значения, т.к. у Foo есть своя логика и именно ее мы тестируем.

Разве юнит тесты не могут быть каскаднозависимыми? Т.е. не выполнились тесты на объектах в тестируемой функции, значит не выполнились тесты и на самой функции.

Нет. Это уже будут не юнит-тесты. Юнит-тесты - атомарны и не должны зависить ни от каких других тестов или инфраструктуры.

Если бы изолированные тесты с моками работали как в теории, то не нужны были бы интеграционные тесты, т.к. вы фактически тестируете интеграцию объекта user в функцию Foo.

Интеграционные тесты тестируют систему в целом. Их количество в десятки, а то и в сотни раз меньше, чем количество юнит-тестов. Это связано с тем, что интеграционные тесты сложны и тяжелы. Кроме этого, они показывают, работает ли система в целом, но они не показывают где именно поломка.

Когда я пришел на прошлый проект, там было около 30 интеграционных тестов, которые исполнялись около 2,5 часов. Я добавил в проект около 1000 юнит-тестов, которые выполнялись всегда вместе с компиляцией и требовали меньше 5 минут времени. При этом юнит-тестами можно покрыть гораздо больше тест-кейсов. Например, я в том проекте добавлял проверку на отказ в правах доступа жесткого диска. Сделать такое в интеграционном тесте очень сложно.

Вообще, странно, что принципы программирования, а конкретно единственность ответственности, у вас легко нарушаются в тестировании, и вы ответственность одного объекта легко размазываете по всем другим местам, где этот объект используется.

Это не так :)

Нужно проверить отсылку почты при каких то условиях. Ваша реализация на реальных вещах?

Я, в отилчии от некоторых сектантов, не придерживающих каких-то принципов 100%. Что нельзя тестировать на реальных вещах, то можно замокать. Но это будут в основном исключения для всяких взяимодействий со внешним миром. А вот БД можно использовать реальную. Точнее копию реальной, пусть даже не полную.

Следил за одним проектом в сети.

Я бы предложил сделать анализ успешных проектов...

Это очень успешный проект. Он очень сильно обогатил своих хозяев, о чём они раньше и мечтать не могли. И плюс они ещё его продали, перед тем, как выжать и привести в совсем ниспадающее состояние. Люди из обычных программистов стали долларовыми мультимиллионерами. Большинство других проектов куда хуже, хотя там поди многое пытались делать по феншую. Феншуйский код вообще с успехом проекта не только мало связан, но и зачастую идёт в разрез и препятствует развитию. Особенно поначалу.

Вообще, странно, что принципы программирования, а конкретно единственность ответственности, у вас легко нарушаются в тестировании, и вы ответственность одного объекта легко размазываете по всем другим местам, где этот объект используется.

Это не так :)

А чего вы боитесь признаться, что это таки так? Можно сказать, что тестирование это не программирование, потому имеет право на другие принципы и подходы, хотя и там и там код. Ну как верстание страничек не программирование, хотя в вёрстке тоже код.

А вот БД можно использовать реальную

Ок, есть у нас 5 программистов работающих над одной задачей и Оракле база.

Как будем всё делить? При это тестов хотя бы 50 и для каждого теста нужно иметь исходное состояние

Это очень успешный проект. Он очень сильно обогатил своих хозяев

Упс,.. у нас разные критерии успешности проектов

Ок, есть у нас 5 программистов работающих над одной задачей и Оракле база.

Он не знает. Он с таким не работал.

А вот БД можно использовать реальную

Ок, есть у нас 5 программистов работающих над одной задачей и Оракле база.
Как будем всё делить? При это тестов хотя бы 50 и для каждого теста нужно иметь исходное состояние

В тесте скрипт создаёт слепок нужной части БД. После теста слепок удаляется. Вам с вашими тестовыми данными примерно то же придётся делать, только руками эти тестовые данные вписывать, или генерить.

Или можно для каждого типа тестов всегда держать слепок, который будет копироваться пре прогоне тестов. А сам слепок - периодически обновляться данными из реальной БД. Всё лучше, чем ваши 50 кейсиков вручную набивать.

Это очень успешный проект. Он очень сильно обогатил своих хозяев

Упс,.. у нас разные критерии успешности проектов

Деньги всему голова. "Если такой умный, почему не богатый?" - умный человек сказал, то есть богатый.

Првильная ситуация или нет?

-----

Конечно правильная.

Ну прикинь - заменил винду на РТОС и вопрошаешь свой вопрос?

А проблема... Блин, сколько раз Я чистил разные кеши от версий дллок...

В тесте скрипт создаёт слепок нужной части БД.

-----

Теперь запусти это все в параллели и, желательно, с разных машин.

Ты же за реальный мир - пусть изначально конкурируют как юзеры.

Когда победишь - тебе будет предложено вместо выделенной тестовой

базы пользоваться живой производственной.

Ну нету другой и железа под нее нету...

В тесте скрипт создаёт слепок нужной части БД

Вопрос был не про это. Как нам разделить базу на х "человек" одновременно. При этом х меняется.

Хотя создание и удаление "слепков" для х тестов тоже интересная задача.

А то что тесты могут исполнятся параллельно, где то еще учитывется?

Деньги всему голова.

Ну прикинь - заменил винду на РТОС и вопрошаешь свой вопрос?

Не нужно ничего прикидывать, окружение не меняется, Есть изменения исключительно в проекте.

Никаких кэшей и прочего..., дополнительно не имеется.

В тесте скрипт создаёт слепок нужной части БД.

-----

Теперь запусти это все в параллели и, желательно, с разных машин.

Ты же за реальный мир - пусть изначально конкурируют как юзеры.

Конкуренция и прочее отрабатывается в самой СУБД, которую тестировать не надо - за вас это уже сделали. А если сама ваша функция должна работать в многопоточном конкурентном окружении, тогда да - надо тестировать.

Как, кстати, на юнит тестах тестируется работа в многопоточке?

Когда победишь - тебе будет предложено вместо выделенной тестовой

базы пользоваться живой производственной.

Ну нету другой и железа под нее нету...

Когда чего-то нету, тогда и действуем соответственно. Но в пределе, из говна конфетку не сделаешь. Но можно побрызгать ароматизатором и обернуть в красивый фантик.

Вот Алекснек не хочет рассуждать, когда чего-то нету или не по правилам. Всё должно быть по феншую, а то он не играет. ))

Вопрос был не про это. Как нам разделить базу на х "человек" одновременно. При этом х меняется.

Хотя создание и удаление "слепков" для х тестов тоже интересная задача.

А то что тесты могут исполнятся параллельно, где то еще учитывется?

Для сложных и запутанных случаев я готов сделать исключение - пишите ваши моки.