AZ
Да, вот вам ещё один яркий признак. Юниты должны проходить на полностью изолированном коде. Если вашему тесту нужна работающая база или любой другой внешний источник данных, то это не unit test.
В ваших словах есть смысл.
Size: a a a
2020 January 16
B
второй вопрос - гораздо важнее: кто должен писать юнит тесты. И тут вечные споры.
СС
имелось ввиду - работающее веб приложение не нужно. То есть, если это веб - билд все же нужен, но бэкенд можно не поднимать.
я все в рамках веба рассуждаю )
я все в рамках веба рассуждаю )
а как тогда работают юниты?)
ИС
второй вопрос - гораздо важнее: кто должен писать юнит тесты. И тут вечные споры.
Очень легко написать код, который выполняет бизнесовую задачу, но будет абсолютно не тестируемым с помощью юнит тестов. Это одна из причин, почему юниты пишут разработчики. Вторая — чтобы выделить из кода атомарный фрагмент логики, который будет покрыт тестами, нужно понимать код всего участка приложения. Почти всегда это будет за границами обязанностей (и часто компетенций) тестировщика.
AZ
Очень легко написать код, который выполняет бизнесовую задачу, но будет абсолютно не тестируемым с помощью юнит тестов. Это одна из причин, почему юниты пишут разработчики. Вторая — чтобы выделить из кода атомарный фрагмент логики, который будет покрыт тестами, нужно понимать код всего участка приложения. Почти всегда это будет за границами обязанностей (и часто компетенций) тестировщика.
И такое бывает. Это и есть фактор сложности для тестирования/автоматизации
B
Очень легко написать код, который выполняет бизнесовую задачу, но будет абсолютно не тестируемым с помощью юнит тестов. Это одна из причин, почему юниты пишут разработчики. Вторая — чтобы выделить из кода атомарный фрагмент логики, который будет покрыт тестами, нужно понимать код всего участка приложения. Почти всегда это будет за границами обязанностей (и часто компетенций) тестировщика.
например - тестирование компонентов angular приложения - передать тестеру или пусть разработчик сам покрывает? и если не успевает - пусть ставит себе в техдолг?
ИС
например - тестирование компонентов angular приложения - передать тестеру или пусть разработчик сам покрывает? и если не успевает - пусть ставит себе в техдолг?
Очень общие вопросы. Если у вас TDD, то он не может "не успеть" покрыть фичу юнитами, т.к. без них не приступит к реализации.
ON
TDD это что-то вроде единорогов, вроде бы существует, но никто их не видел
RL
TDD это что-то вроде единорогов, вроде бы существует, но никто их не видел
RL
Он есть, но немножко не такой, как можно было бы предположить*
😁
😁
AZ
TDD это что-то вроде единорогов, вроде бы существует, но никто их не видел
Ага. Ну на бумаге вроде есть какой-то смысл, а в реальности встречается редко.
IG
Как и agile...
IG
Но это уже немного флуд
RL
Как и agile...
А аджайл похож на боженьку, помогает только если в него верить😆
AZ
Кстати вроде видел когда-то вакансии для автоматизаторов, где понимание тдд было бы плюсом.
JC
"Аджайл же - клетка ... А мы в ней - дрессированные львы"
ON
Кстати вроде видел когда-то вакансии для автоматизаторов, где понимание тдд было бы плюсом.
понимание это одно, а вот реальное практическое использование - совсем другое, как по мне ТДД это что-то вроде когда тебе приходится взбираться по верёвочной лестнице вверх ногами, дело привычки)
ИС
понимание это одно, а вот реальное практическое использование - совсем другое, как по мне ТДД это что-то вроде когда тебе приходится взбираться по верёвочной лестнице вверх ногами, дело привычки)
Поулчил ТЗ, составил скелет в коде из классов и методов, которые будут решать задачу, накидал юнитов с ожидаемыми кейсами и результатами, набил методы мясом, уверенный, что они точно правильно работают. Чего сложного?
O
TDD это что-то вроде единорогов, вроде бы существует, но никто их не видел
ну у меня два таких единорога прям перед глазами сейчас сидят. если не врут конечно ))
GD
да не, врут небось. это фантастика.