Модульное тестирование - Comments

Вполне доходчиво и понятно, интересно было бы прочитать про mock тестирование

Ну почему же каждый метод тест индивидуальный, кто автору phpunit внушил сделать именно так.

Reflesh, не совсем понял комментарий. Тесты дробятся на методы, чтобы было проще найти причину ошибки. Если у вас в одном методе теста слишком много тестируется, то локализовать ошибку будет сложнее, ибо не понятно, что именно привело к ее возникновению, но если разбить один большой метод теста на 10 маленьких и в процессе тестирования 2-3 из этих методов не пройдут, то будет сразу понятно, в чем была причина ошибки.

Башка, Вся проблема в том, что setUp и tearDown вызываются для каждого метода теста, то-есть каждый метод теста индивидуальный, это такое убожество.... А методы которые вызываются вначале класса и в конце, статитка. Сохранить что-то для следующих методов тестов, только в статитки, это дерьмо и еще хуже. Лучше и придумать нельзя было...

Пишем тесты для тестирования классов которые работают с бд, и тут в setUp для каждого теста наполняем бд данными а в tearDown удаляем все, и такое создание и удаление для каждого метода теста, др***во!

Не, ну конечно можно всю эту логику в трейты запихать, но все равно это дерьмо! А тестирование фреймворков, для каждого теста инициализируется фрейм, либы, бд заполняется данными и т.д.. Др***во, дерьмо!

А, и тут автор либо не знает о setUp либо, обходит его стороной.

А mock, так это вообще, что за чудо конструктор лего....

Вся проблема в том, что setUp и tearDown вызываются для каждого метода теста, то-есть каждый метод теста индивидуальный, это такое убожество

Вас никто не заставляет использовать методы setUp и tearDown при тестировании. Я, к примеру, пользуюсь этими методами для совсем уж простеньких тестов, для остального я использую фабричные методы.

Сохранить что-то для следующих методов тестов

Сохранять что-то между методами теста это моветон.

тут в setUp для каждого теста наполняем бд данными а в tearDown удаляем все

Так делать не рекомендуется. Если есть возможность, необходимо заменить работу с базой mock объектами, если такой возможности нет, то создавать данные в базе следует на уровне setUpBeforeClass метода.

А mock, так это вообще, что за чудо конструктор лего

Mock это Mock, не больше, не меньше.

Башка, это я бешусь все из-за того что у Laravel все укладывается в setUp и tearDown и он заставляет заниматься таким онанизмом, и все им занимаются.

Так делать не рекомендуется. Если есть возможность, необходимо заменить работу с базой mock объектами, если такой возможности нет, то создавать данные в базе следует на уровне setUpBeforeClass метода.

Статика

Reflesh, я плохо знаком с Laravel, не могу по этому поводу ничего сказать.

Статика

В данном случае не вижу причин не использовать статику.