Обновить
58
0
Пуштаев Вадим@pushtaev

Пользователь

Отправить сообщение
Пардон, должно выглядеть так:

Если в требованиях нет описания всех возможных случаев, то нет и требования покрывать их тестами и вообще как-то особо обрабатывать.

Классы эквивалентности меняются с реализацией. https://habrahabr.ru/company/mailru/blog/274771/ — п2.
Не сомневайтесь, автор заявляет именно это. «TDD работает, потому что врачи моют руки». Надо себе футболку такую сделать.
Если в требованиях нет описания всех возможных случаев, то нет и требования покрывать их тестами и вообще как-то особо обрабатывать.
Классы эквивалентности меняются с реализацией. https://habrahabr.ru/company/mailru/blog/274771/ — п2.
Да, статья — шаг вперед по сравнению с советами класть плитку вместо программирования всем, кто не использует TDD. Однако сообщество все еще ждет от евангелистов TDD стройной теории и ответов на вопросы и возражения.

Спасибо! Учтите, что test-first ≠ TDD :).
Да-да, я ровно об этом: явно нужны какие-то дополнительные пояснения, ибо постулаты слишком уж о много о чем умалчивают. Эта статья, кстати, как раз этим и занимается: вносит дополнительные пояснения к постулатам test-first.
Это любопытный взгляд на вещи, но легко видеть, что с ним в терминах статьи все еще хуже: в этом случае даже интерфейс до написания функции неизвестен (т. к. то, что надо использовать is_german_letter, я придумаю только на стадии реализации).

А вот в процессе реализации как раз все становится, как вы говорите. Иначе это можно выразить так: формулировка функции с «посчитай немецкий буквы» меняется на «посчитай буквы, которые is_german_letter».
Спасибо! Я ждал вашего комментария, рад, что понравилось :).
Я все это прекрасно понимаю :). Я говорю о том, что формулировке «пишите минимальную реализацию» явно не хватает кое-каких деталей (примерно тех, которые вы сейчас добавляете).
Что такое «теоретическое доказательство верности программ»?

Формальная_верификация

Почему у вас входные данные зависят от реализации метода, а не наоборот?
Нормальным образом можно это зафиксировать написав все тесты строго до реализации.

Вот об этом как раз статья. Зафиксировать столько, сколько нужно раньше реализации — не получается.

Я вижу тут или противоречие, или «аргумент» против TDD.

Почти: это аргумент против test-first в его классическом понимании, да.
и уже пишите код сложения

Или хардкожу 1+0=1, и все заново — речь про это.
Меня всегда пугала формулировка про «минимальную реализацию». Минимальная реализация — это, может быть, захардкодить ответ на тестовые значения. Я понимаю, что подход предполагает не это, поэтому, думается, надо формулировку как-то переосмыслить.
А вообще, я не сильно понял, о чём статья.

Примерно об этом:
Controlling complexity is the essence of computer programming. — Brian Kernighan
Понятно, что отображается содержимое уровня на экран поэкранно, но почему при разговоре о хранении уровня мы говорим про экраны? Экраны скроллятся гладко, почему повторяются именно экраны целиком? Почему не по полтора? По 1,7? Почем размер хранимого экрана совпадает с реальным?
Ubisoft потеряли исходники дополнений к Третьим героям, а вы говорите NES :).
Нас учили, что «взлом» от «невзлома» принципиально отличается наличием усилий по преодолению защиты, которые определяются судьей на глаз. В этом смысле, если пароля нет, и я просто нажал кнопку connect — это не неправомерный доступ. Иначе бы можно было бы привлекать любого, кому повезло словить баг, роняющий сервис :).
Это уже не первая статья на тему «не делайте классы, объекты которых создаются лишь на единый вызов метода, делайте вместо них функции». Аргументы, на мой взгляд, каждый раз неубедительные, продолжаю так делать :-).
Это хороший, годный паттерн Method Object: sourcemaking.com/refactoring/replace-method-with-method-object
И это как раз верное понимание.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность