-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
2TDD infected
- Автор темы HraKK
- Дата начала
Духовность™
Продвинутый новичок
давайте в онлайн консультируйте!
atv
Новичок
Но интерфейс то класса у тебя должен же быть. Не реализация, а интерфейс.
А зачем их тестировать отдельно? Они всегда работают в паре и составляют единый интерфейс класса, который, в данном случае, гласит, что установив значение сеттером, можете получить это значение геттером. Вот и тестируешь это поведение.
нифига не инфектед, но:
>> как можно протестировать Front Controller?
mocks, vfsStream
>>есть класс хранилище, у него есть 2 внешний метода - геттер и сеттер.
>>Как их протестировать отдельно друг от друга?
а зачем? если геттер+сеттер в паре работают ожидаемо, какая разница, что там внутри происходит?
>> как можно протестировать Front Controller?
mocks, vfsStream
>>есть класс хранилище, у него есть 2 внешний метода - геттер и сеттер.
>>Как их протестировать отдельно друг от друга?
а зачем? если геттер+сеттер в паре работают ожидаемо, какая разница, что там внутри происходит?
Интерфейс у FC? как такового нету, но даже если и есть то - dispatch()
Что это даст?)
Не знаю, для меня логично что 2 различных действия тестируются 2 различными тестами. Давайте уже 1 тест делать на всесь аппликейшен, но же все равно делает одну вещь?
Непонятно с каких пор FC работает с FS?
ну с точки зрения функционала, что делает FC?
1. выгребает из переменных окружения (или ещё откуда) запрос
2. передаёт запрос роутеру (или какому другому компоненту) на разбор
3. по разобранным параметрам выполняет команду
исходя из функционала и тестируй, что: правильно выбрал запрос, правильно его передал в роутер, правильно интерпетировал результаты роутинга, правильно запустил конкретный контроллер.
1. выгребает из переменных окружения (или ещё откуда) запрос
2. передаёт запрос роутеру (или какому другому компоненту) на разбор
3. по разобранным параметрам выполняет команду
исходя из функционала и тестируй, что: правильно выбрал запрос, правильно его передал в роутер, правильно интерпетировал результаты роутинга, правильно запустил конкретный контроллер.
Не в зависимостях дело, избавление это старый пройденный путь, просто я пытаюсь идеологически построить тест так, что я не знаю функциональной реализации, а не вначале код потом тест. А вот это пока тяжело дается.
Ладно, завтра с утра посмотрю, просто тяжелый день был, думаю просто мозги перегрузились - всю ночь не спал(( Завтра на трезвую голову оценю.
Ладно, завтра с утра посмотрю, просто тяжелый день был, думаю просто мозги перегрузились - всю ночь не спал(( Завтра на трезвую голову оценю.
Требования от класса естественно есть. Ака Интерфейс, то есть то что я ему должен давать, что он должен делать и выдавать.
Сейчас вроде все получается, но пока точно не могу сказать так как чтоб его полноценно отестить мне надо описать всю его переферию, чем сейчас и занимаюсь. Завтра может выложу то что получилось, обплюете
Кстати никто не знает как заставить класс реагировать на next()?
Сейчас вроде все получается, но пока точно не могу сказать так как чтоб его полноценно отестить мне надо описать всю его переферию, чем сейчас и занимаюсь. Завтра может выложу то что получилось, обплюете
Кстати никто не знает как заставить класс реагировать на next()?
whirlwind
TDD infected, paranoid
Ну это как раз и есть оно. Примерно так:
1. Модель требований: use cases + software requirements specification + glossary
2. Метамодель: диаграммы последовательностей + классы предметной области
3. Проектная модель: то же самое что метамодель + все служебные классы (базы, фабрики, етц) и диаграммы взаимодействия между ними
4. Реализация: разработка теста -> реализация класса