ZZZ
Но сделать нормально не успеваю вообще никак.
Мне как-то надо было за две недели написать прогу, иначе клиент бы ушёл к другому (более скоростному), ну, я написал, а в конце оказалось, что нужно ему что-то другое, так что он всё равно ушёл, а код я выкинул. Это был наскорячный код, который потом никуда не подходил больше (почему и выкинул). То же самое и с музыкой - нельзя под музыку писать, иначе потом ошибок много. Зато все продуманные проги, написанные внимательно (без музона), работают годами и открыты для поднятия их версий. Поэтому и UML у меня сейчас обязателен, хоть на него время и уходит.
По тестам же, какая-нибудь маленькая шпунька (и далеко не центральная) может требовать кучи всяких проверок, чтобы не ловить потом глюки в ней, когда всё в целом будет работать.
Здесь в одной из задач написал себе случаи на потом, которые считаются маленькой недописанной частью (устал писать основные тесты):
[guest@localhost prj]$ git diff -- tests/test_accviewer.py
diff --git a/tests/test_accviewer.py b/tests/test_accviewer.py
index a783c45..9458a18 100755
--- a/tests/test_accviewer.py
+++ b/tests/test_accviewer.py
@@ -117,3 +117,22 @@ class AccViewerHandlerGoodInput(unittest.TestCase):
if __name__ == '__main__':
unittest.main()
+
+# пустой список аккаунтов
+# заголовок может быть многострочным
+# заголовок может содержать юникод
+# заголовок выводится на каждой странице
+# сообщение может быть многострочным
+# сообщение может содержать юникод
+# сообщение выводится на каждой странице
+# общее количество аккаунтов выводится
+# количество страниц вычисляется правильно
+# аккаунт переносится на следующую страницу
+# пустое название в аккаунте заменяется
+# пустой сервер в аккаунте заменяется
+# пустой пользователь в аккаунте заменяется
+# номера сообщения выравниваются одинаково
+# номер, превышающий ширину поля, укорачивается
+# отрицательный размер страницы порождает исключение
+# отрицательная ширина поля номера порождает исключение
+# список акканутов может быть генератором
[guest@localhost prj]$
И каждый тест надо сделать по TDD - запустить, проверить, написать, запустить, проверить, чтобы случайно не написать тест, который якобы что-то проверяет, но на самом деле ничего не проверяет.