- чуть чуть поправили код
- прогнали тесты и убедились что ничего не сломали
- чуть чуть подправили тесты
- прогнали тесты и убедились что вы не сломали ничего в тестах, в этом случае гарантом того что все работает выступает ваш код
Ух... как все запущено...
У вас выборка не репрезентативна. Я понимаю еще в два раза, но в 10... Опять же TDD не регламентирует вам сколько у вас должно быть покрыто тестами кода, 10% или 100%.
Когда у вас тестов в 10 раз больше чем кода, это повод задуматься.
Либо у нас мегакритичная часть приложения
которая должна учитывать все позитивные и негативные сценарии на всех пограничных случаях
Вообще доводы в духе "жалко удалять" это смешно.
Вот я пытался бороться с говнокодом, вводили кодревью и прочее.... и в итоге я всеравно пришел к тому что в этом нет никакого value, пусть себе будет до рефакторинга. Работает и ладно.
Повторюсь, у меня есть 3 слоя:
Жалко только потраченного времени но это быстро проходит.
Ну и зачем так делать? Можно например написать не 1 тест а 10, я так иногда делаю когда более-менее уверен в том что как должно быть. Но 100 тест кейсов... это явно перебор.
А в чем разница то? Реальные данные вы получите не раньше чем выкатите разрабатываемый функционал в продакшен или как минимум на стэйджинг, все остальное и так составные данные.
Как? По архитектурным причинам? Маловероятно, либо у нас система с очень большой связанностью, чего я лично стараюсь избегать. Если фича не подходит потому что идет в разрез с уже заимплеменченными фичами, эта проблема устраняется еще на этапе планирования или бизнес анализа, когда хотелка приходит в бэклоги, на грумингах, сторимэппингах и прочих штуках.
У Дяди Боба скажем довольно жесткие правила:
И ни слова о интерфейсах и прочего.
Да и юнит тестами у меня покрывается только слой бизнес логики и ооочень редко инфраструктурный слой.
Так программа или UI?
все дробится на VO и объекты-конфигурации и т.д. Так же я люблю для каких-то сложностей пихать через дабл диспатч сервисы в методы моих бизнес-объектов.
Как это понимать? Вы месяц тупо писали тесты? Это как бы идет в разрез с TDD если что.
Вот в этом и ошибка, TDD подразумевает что мельчайшие подробности вы обдумываете в тот момент, когда пишите тесты.
Используя TDD вы все это видите еще на этапе написания тестов
проблемы открываются раньше
Скажем покрывать тестами код, который должен только заменить данные (по сути сеттеры, хотя я сеттеры аля setSomething не пишу).
Я это к чему, можете сформулировать эти самые правила TDD?
Этого не может быть, если вы практикуете TDD.
Для этого может быть только одна предпосылка - редкое изменение требований, когда часть функционала больше не нужна.
>>> class Test:
... def __init__(self,value):
... self._value = value
...
... def __lt__(self,other):
... print('lt')
... if type(other) != Test:
... raise ValueError('comparing object must be of type Test')
... return self._value < other._value
...
>>> a = Test(10)
>>> b = Test(20)
>>> a < b
lt
True
>>> a > b
lt
False
>>>>>> class Test:
... def __init__(self,value):
... self._value = value
...
... def __lt__(self,other):
... if type(other) != Test:
... raise ValueError('comparing object must be of type Test')
... return self._value < other._value
...
>>> a = Test(10)
>>> b = Test(20)
>>> a < b
True
>>> a > b
False
>>> a < 3
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 7, in __lt__
ValueError: comparing object must be of type Test
>>> a > 3
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: Test() > int()
>>>Если вы определяете __lt__ (<), то неявно автоопределится __gt__ (>), но не __ge__ (>=) и __le__ (<=).
>>> class A:
... def __lt__(self, v):
... return hasattr(v, 'x')
...
>>> class B:
... x = 1
...
>>> class C:
... y = 1
...
>>> a, b, c = A(), B(), C()
>>>
>>> a < b
True
>>> a > b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() > B()
>>> a == b
False
>>> a != b
True
>>> a <= b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() <= B()
>>> a >= b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() >= B()
>>>
>>> a < c
False
>>> a > c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() > C()
>>> a == c
False
>>> a != c
True
>>> a <= c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() <= C()
>>> a >= c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() >= C()
>>>The current C++ standard, C++11, made auto_ptr deprecated, replacing it with the unique_ptr class template.
Вот функция из одной строки:
func(a, b) { return a + b }Вот тесты:
Ещё можно напридумывать; главное, чтобы они покрывали случаи где это всё может выпасть.
Итого, на одну строку приходится множество тестов.
Ну да, кривовато они ставятся, потому что кое-кто не знает про предпросмотр. ;)