SP
можешь погуглить testing vs checking
Size: a a a
2021 May 23
DT
Извини еслм не уточнил
SP
https://www.developsense.com/blog/2009/08/testing-vs-checking/
> Checking Is Confirmation - вот это то что твои тесты делают обычно
> Testing Is Exploration and Learning - тут из "автоматизации" это хаос тестирование например... или там property based testing
> Checking Is Confirmation - вот это то что твои тесты делают обычно
> Testing Is Exploration and Learning - тут из "автоматизации" это хаос тестирование например... или там property based testing
SP
я к тому что "такой вижен" это просто "тесты хорошо без тестов плохо". Ну то есть считаю это диким упрощением.
SP
например ты можешь иметь 100% покрытие кода, все у тебя формализовано и т.д. но бизнес пипл твои тесты читать не может и как следствие держат где-то в вики отдельную спецификацию которая быстро аутдейтится и на основе неправильных данных пилят новые фичи. Есть ли толк от такой формализации?
SP
я больше сча сталкиваютсь с ситуациями когда фича есть, формализована, тесты даже есть но нахер она нужна инфы нет)
ак
Мне нравится определение Мартина тут:
'TDD is when you write tests on something you already know you wanna write'. И подразумевается, что таким образом ты найдёшь то, чего ты Не хотел писать, а надо бы)
'TDD is when you write tests on something you already know you wanna write'. И подразумевается, что таким образом ты найдёшь то, чего ты Не хотел писать, а надо бы)
DT
Норм упрощение как по мне, в плохо потому что не быстрого способа удостовериться в относительной правоте
DT
Ну это никак не дискредитирует тдд как методологию
SP
я и не пытаюсь ее дискридитировать, я лишь говорю что не стоит там регрессию и "тесты" там целью делать. И тогда TDD будет проще и лучше.
DT
В правоте относительно своих суждений о коде или решении
DT
Эт не цель а приятные бонусы
SP
ну то есть мне не нравится "смешивание" TDD (цель которой - только формализация того че как должно работать и внутренее качество) и "регрессии" (тут больше про внешнее качество, юнит тесты в целом не про это)
SP
потом в итоге сложности "почему мы должны писать и приемочные и юнит тесты" "а когда писать те а когда другие? а вот это надо в юнитах писать"? травма сорян
AV
Добрый вечер. Хотелось бы узнать, какие бизнес правила должны соблюдаться и кто за эти правила собственно отвечает.
За пример возьму смену почты и ее уникальность. Я ее могу решить: уником в базе, могу в репозитории сделать метод на наличие существующей почты, могу перенести эту проверку в доменный сервис и проверять там, могу доменный сервис прокинуть в агрегат и проверять там.
Где найти правильную границу?
За пример возьму смену почты и ее уникальность. Я ее могу решить: уником в базе, могу в репозитории сделать метод на наличие существующей почты, могу перенести эту проверку в доменный сервис и проверять там, могу доменный сервис прокинуть в агрегат и проверять там.
Где найти правильную границу?
AV
Собственно из этого вытекает ещё и вопрос, а все ли бизнес правила именно "бизнес"
SP
Агрегат отпадает по причине того что он про другие email знать ничего не должен, доменный сервис не гарантирует атомарность, в итоге у тебя два варианта - юник констрейнт в базе или разрешить дубли и разруливать их как-то по-другому.
AV
А почему плох вариант с репозиторием, который мы будем дергать в application service?
SP
Нет не все и среди тех которые "бизнес" тоже не все одинаково важны
SP
Кури в сторону true invariant - дубли в email как правило ими не являются