D
Size: a a a
2020 October 02
ПГ
Привык я так
Типа вот такие конструкции не будут работать больше?
https://github.com/ElisDN/demo-project-manager/blob/master/manager/src/ReadModel/User/UserFetcher.php
https://github.com/ElisDN/demo-project-manager/blob/master/manager/src/ReadModel/User/UserFetcher.php
AD
Типа вот такие конструкции не будут работать больше?
https://github.com/ElisDN/demo-project-manager/blob/master/manager/src/ReadModel/User/UserFetcher.php
https://github.com/ElisDN/demo-project-manager/blob/master/manager/src/ReadModel/User/UserFetcher.php
Да
SP
Даже наименования функций пишутся сначала в тестах а затем уже по итогам тестов - создаются в классах?
в TDD тесты служат обоснованием что тебе вообще какой-либо код писать надо. Нет падающего теста - не нужно писать код. Такой подход достаточно занятные эффекты имеет и на проектирование и на процесс тестирования и на формализацию требований...
DD
Но все равно не тесты раньше кода. Хоть какая-то композиция приложения быть должна.
VS
Но все равно не тесты раньше кода. Хоть какая-то композиция приложения быть должна.
В Тдд есть стадия рефакторинг, там и можешь разгуляться. Красный тест - код, что фиксит тест - рефакторинг.
DD
А абсолютный сторонник тестов, как юнит, так и функциональных. Но концепция
tests firstменя как инженера как минимум ставит в тупик. По мне это ситуация выглядет так: Голая степь, надо запустить спутник, делаем тест - спутник наверху? False. И что дальше?
VS
А абсолютный сторонник тестов, как юнит, так и функциональных. Но концепция
tests firstменя как инженера как минимум ставит в тупик. По мне это ситуация выглядет так: Голая степь, надо запустить спутник, делаем тест - спутник наверху? False. И что дальше?
Дальше делаем тест- запущенный спутник наверху.
T🐜
А абсолютный сторонник тестов, как юнит, так и функциональных. Но концепция
tests firstменя как инженера как минимум ставит в тупик. По мне это ситуация выглядет так: Голая степь, надо запустить спутник, делаем тест - спутник наверху? False. И что дальше?
ракеты прежде чем построить и запустить тщательно просчитывают целыми НИИ всякими.
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
DD
The Ant 🐜
ракеты прежде чем построить и запустить тщательно просчитывают целыми НИИ всякими.
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
Но в любом случае ты чтото делаешь ДО тестов, не так ли. На бОмажке или пхпстОрме
VS
The Ant 🐜
ракеты прежде чем построить и запустить тщательно просчитывают целыми НИИ всякими.
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
Тдд не про это совсем
T🐜
Но в любом случае ты чтото делаешь ДО тестов, не так ли. На бОмажке или пхпстОрме
ДО тестов пилишь проектную документацию от и до. Вот чо делаешь.
T🐜
Vlad Sobenko
Тдд не про это совсем
а про что?
VS
The Ant 🐜
ракеты прежде чем построить и запустить тщательно просчитывают целыми НИИ всякими.
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
Также и с тестами. Сначала проектируешь на бомашке. Потом пилишь интерфейсы, которые покрываешь тестами.
А потом уже и код можно писать. Это ж простая концепция, не?
Тдд про поиск решения через тесты. А не про точную реализацию схемы, продуманную до этого.
SP
А абсолютный сторонник тестов, как юнит, так и функциональных. Но концепция
tests firstменя как инженера как минимум ставит в тупик. По мне это ситуация выглядет так: Голая степь, надо запустить спутник, делаем тест - спутник наверху? False. И что дальше?
В этом и смысл и не для всех кейсов эти подходы годятся. Ты лучше думай о следствии такой перестановки и все остальное будет уже чисто инженерной проблемой
T🐜
Vlad Sobenko
Тдд про поиск решения через тесты. А не про точную реализацию схемы, продуманную до этого.
не понимаю как это... расскажешь?
VS
В этом и смысл и не для всех кейсов эти подходы годятся. Ты лучше думай о следствии такой перестановки и все остальное будет уже чисто инженерной проблемой
На выходе будет максимально простое решение, подтвержденное тестами.
VS
The Ant 🐜
не понимаю как это... расскажешь?
У тебя есть требования. И ты максимально простым путем их реализуешь через написание тестов.
SP
В этом случае тесты будут твоим дизайн документом :)