главное запомни юнит тест тестирует только один класс, все остальное в идеале мокается и stub(заглушки) контролируемое поведение должно быть

юнит тест не тестирует зависимости и тд

это уже другие виды тестов)

главное запомни юнит тест тестирует только один класс, все остальное в идеале мокается и stub(заглушки) контролируемое поведение должно быть

не обязательно класс

модуль != класс

модуль оО?

unit - модуль

модуль в понимание java ?

в php namespace

У меня каждый метод тестируется )

модуль в понимании бизнес-логики

На каждый метод один класс тестов

а ну да так согласен)

модуль в понимании бизнес-логики

так ок)

если вы будете тестировать отдельные классы, но получите сильную связность тестов и кода

и на каждый чих придется править тесты

и на каждый чих придется править тесты

Нет

Нет

как нет?

У меня в модуле есть структура классов, она не может поменяться

Она может стаьь больше или логиас изменится

Но большая часть тестов всегда будет работать

ух чувствую холивар

но канонично тесты делать для классов или даже лучше для методов отдельно)

как тут написали

имхо без пруфов

От метода deliveryPrice я всегда жду определенное значение

тестируя классы ты затрудняешь рефакторинг, делаешь код ригидным

но канонично тесты делать для классов или даже лучше для методов отдельно)

нет

тестируя классы ты затрудняешь рефакторинг, делаешь код ригидным

так я тестирую экземпляр класса

От метода deliveryPrice я всегда жду определенное значение

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

а пруфы есть в эту сторону

почитаю по другую стороны

тут тонкость понимания слова модуль

тестируя классы ты затрудняешь рефакторинг, делаешь код ригидным

Возможно ты говоришь сейчас о ddd, но это фантастика в моем проекте

ddd, tdd еще много букв d

tdd, ddd, bdd

У нас трехкилометровые назвпния классов, никаких неймспейсов, сильнейшая связанность и всё остальное

zend ?

Я пишу юнит тесты чтобы быть уверенным, что мои куски раблтают как надо

:D

"на пальцах" если, ты тестируешь не класс, а интерфейс, не метод а поведение

ммм

юнит тесты на интерфейс

о я этим вопросом многих насиловал

допустим есть A, B оба реализуют I

Что у меня какая-то гибкость потеряется...пф, конь, ее нет и не было. У нас даже куски html в прям в классах есть

мне писать IUnitTest

или AUnitTest, BUnitTest ?

Что у меня какая-то гибкость потеряется...пф, конь, ее нет и не было. У нас даже куски html в прям в классах есть

у меня кое-где sql из шаблонов выполняется, это не значит, что не надо стараться сделать лучше)

как каноничненько )

мне писать IUnitTest

ты про название или про смысл?

у меня кое-где sql из шаблонов выполняется, это не значит, что не надо стараться сделать лучше)

Я делаю. Модули которые выпадают на меня рефакторю в силу возможностей

Но юнит тесты пользую только чтоьы проверриьь, что все работает как надо

ты про название или про смысл?

ну думаю по названию пока, потом от названия смысл понятен надеюсь будет

интерфейс описывает поведение: если дернуть этот метот с таким параметром, то вот тут загорится лампочка такого-то цвета

просто хочу поэтапно от простого к сложному

ок

согласен

тестируем интерфейс получается

У нас трехкилометровые назвпния классов, никаких неймспейсов, сильнейшая связанность и всё остальное

я тоже пишу так как пишут в джаве

и назвать логично IUnit - с этим не согласен

интерфейс это не имя файлика с кодом, а именованное поведение бизнес логики

DriverInterface отличный пример бизнес логики

если у тебя есть интерфейс "зажигатель лампочки", то ты его и должен проверять

хорошо

у меня есть интерфейс зажигатель лампочки

ERROR: S client not available

и 2 лампочки старая и энерго сберегающая

$type = 'type_message'; if ($type === 'type_1') как сюда регулярку чтоб проверяла только соответвие на type а дальше не важно

и назвать логично IUnit - с этим не согласен

Unit нинужин

это не Unit

Unit нинужин

ок, если тебе так будет удобней)

как проверить что они горят?

фотодатчиком

в интерфейс зажигания лампочки кинуть метод типо isLight ?

нет

у тебя есть фотодатчик

или это на уровне объектов лампочек проверять?

в виде твоего тестирующего инструмента

у тебя есть фотодатчик

я вижу ты очень остроумен

он проверяет - загорелась лампочка или нет

не очень

но пожалуй выше среднего по больнице

в интерфейс зажигания лампочки кинуть метод типо isLight ?

ты не лампочки тестируешь, а патрон для них. проверь его на соответствие госту и на то, чтобы напряжение в нем было какое нужно

$type = 'type_message'; if ($type === 'type_1') как сюда регулярку чтоб проверяла только соответвие на type а дальше не важно

на тип? if тип такой то равен != '' или == ''

ты не лампочки тестируешь, а патрон для них. проверь его на соответствие госту и на то, чтобы напряжение в нем было какое нужно

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

у нас есть лампочка (какая то) и мы говорим

гори

на тип? if тип такой то равен != '' или == ''

чтоб проверяло соответсвие до _ а дальше если любой текст шло в это условие

отказать

гори

и смотрим, что говорит фотодатчик

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

эти детали и есть интерфейс

чтоб проверяло соответсвие до _ а дальше если любой текст шло в это условие

preg что то там была функция поищи и засунь в условие если возращает true и внутри ещё проверку

но уже на текст

preg что то там была функция поищи и засунь в условие если возращает true и внутри ещё проверку

поискать я и сам могу. мне нужен код

а проще регуляркой там \w кажется

эти детали и есть интерфейс

получается: лампочка->включить(патрон); мы заменяем

общением на стандарты и подачи тока

и тд