TDD: это мешает хорошему дизайну API? [закрытый]

TDD приводит к возникающему дизайну , который в конечном итоге создает очень удобный и расширяемый API. TDD не о тестировании. Речь идет о создании стыков в коде, которые можно использовать для добавления поведения по мере того, как вы узнаете больше о своем проекте.

Большинство вещей, которые вы указали как недостатки TDD, многие считают элементами хорошего дизайна.

В частности, обратите внимание на идею передачи чего-либо вместо чего-то метод должен «просто знать» - последнее часто приводит к синглетонам или другим анти-связным конструкциям.

Хотя может быть правдой, что вы можете получить проект, в котором только некоторые аспекты для поддержки тестируемости, это не обязательно плохо.

Однако, как правило,если вам нужно переосмыслить свой дизайн, чтобы сделать его тестируемым, вы в целом придете к дизайну, который лучше с точки зрения связности и соответствия назначению - при этом остается гибким в том смысле, что его можно легко изменить на каковы бы ни были ваши будущие потребности посредством рефакторинга, потому что у вас есть тесты, которые дадут вам уверенность в быстром внесении изменений.

Я согласен на 100% с основными ответами. Но на самом деле это зависит от того, что вы подразумеваете под «хорошим дизайном API». TDD приводит к тестируемому, модульному, рабочему коду, но, в конце концов, наиболее важным аспектом кода TDD является тестируемость.

Вы обнаружите, что это приводит к другому дизайну, чем другие процессы. Вы обнаружите, что тестируемый код может раскрыть на несколько битов своих внутренних компонентов больше, чем может раскрыть чистый API.

Во многих случаях может иметь смысл использовать TDD для создания рабочего кода, а затем - как отдельный шаг - вытащить API. В противном случае у вас есть две силы, которые несколько конфликтуют: простой API и тестируемый код.

Это тонкий момент, и в целом TDD предоставит гораздо лучшие API, чем проектирование из башни из слоновой кости.

Возможно, вы захотите взглянуть на новоязную языковую работу А.О. Гилада Браха, чтобы увидеть некоторые соответствующие API и дизайн языка.

Напротив, поскольку вы используете свои методы, думая как пользователь, при написании тестов, вы обнаружите проблемы, которые возникнут у вашего пользователя, когда вы его напишете. Фактически, вы получите намного более чистый и удобный интерфейс, чем то, что вы написали бы в противном случае.

Нет, я считаю, что TDD обычно поощряет хороший дизайн. Вещи, которые легко тестировать, часто легко использовать и в производственной среде ... потому что, создавая тест, вы думаете: «Что бы я хотел сделать дальше?» а затем заставить его работать.

Практикуя TDD, вы вынуждены продумывать «сценарии использования» для API, как программист собирается использовать классы / методы, и вы получите очень удобную структуру. Если вам нужно создать сотню FooFactory и BarAuthenticator или API становится «ультрамодульным», как вы говорите, вы, вероятно, заметите это при написании тестового кода и подумайте, как это упростить.

Что касается параметров и внедрения зависимостей - я обычно нахожу, что зависимости становятся намного понятнее с использованием TDD. Обычно они являются аргументами конструктора, а не аргументами метода, но разъяснение того, что реализация API требует аутентификатора, источника случайности и т. Д., Полезно для понимания того, что он делает. Вы можете быть уверены, что код не попадет в сеть или удаленную базу данных, потому что он скрывает эти вещи в своей реализации. Подобные скрытые детали - это то, что затрудняет использование API в тестовой среде.

Обратите внимание, что когда зависимости являются частью вызова конструктора, они не являются частью интерфейса, который может реализовать класс - зависимости внутри интерфейса обычно скрыто, но TDD означает, что реализация раскрывает их очевидным образом.

Хороший источник информации о внедрении зависимостей и TDD можно найти в блоге Google Testing Blog . Обратите особое внимание на сообщения Мишко Хевери или посмотрите некоторые из его видео на Youtube: Не ищите вещей и еще .

Суть TDD в том, что мы пишем тесты, которые вызывают код в процессе его разработки. Следовательно, мы должны получить чрезвычайно удобный интерфейс. Конечно, это не случайно. Нам еще предстоит сделать правильный выбор.

Я использую TDD и думаю, что он хорошо работает в отношении построения API, но я думаю, что API, особенно те, которые вы предоставляете внешним клиентам, - это область, в которой вам нужно немного больше предварительный дизайн, чем обычно при использовании TDD. TDD так же сильно зависит от рефакторинга, как и от test-first. Используя API, у вас не всегда есть роскошь как реорганизовать сигнатуры ваших методов, так и поддерживать чистый дизайн. Если вы не будете осторожны при проектировании своего интерфейса заранее, вы можете столкнуться с уродливым интерфейсом, который поддерживает несколько методов, выполняющих очень похожие вещи, просто чтобы сохранить обратную совместимость с вашим существующим API и в то же время продвигать ваш дизайн вперед.

Если У меня есть API, который я буду предлагать внешним пользователям, Обычно мне нужно больше времени, чтобы подумать о подписи и сделать ее как можно ближе к «правильной», прежде чем начать процесс разработки. Я также заранее и часто показываю его своим клиентам, чтобы получить отзывы о нем, чтобы мы как можно быстрее пришли к стабильному интерфейсу. Негласный рефакторинг для улучшения реализации без изменений интерфейса - не такая уж большая проблема, но я хочу быстро получить стабильный интерфейс и готов заранее вложить больше средств, чтобы получить его.

С традиционным дизайном API легко загнать себя в угол: вы можете получить API с множеством скрытых зависимостей (например, классу A нужен B, нужен C, нужен D, и если вы измените порядок, в котором инициализируются классы, все начинает ломаться).

TDD гарантирует, что отдельные части остаются отдельными. Это также позволяет вам увидеть свой API с очень необычной точки зрения: как пользователь / потребитель. Ваш первый вопрос: «Как мне это использовать?» а не "Как я хочу, чтобы API выглядел?" Последний может заманить вас в скрытую ловушку, в то время как первый ведет к тому, что я называю «интуитивным API»: он ведет себя так, как ожидалось.

Небольшой совет: не делайте TDD своей религией. Это инструмент, и некоторые проблемы нельзя решить с помощью некоторых инструментов. Так что, если TDD не не работает на вас по любой причине, тогда ничего страшного. Используйте столько TDD, сколько хотите. Не будь фанатиком по этому поводу. Со временем вы найдете свою зону комфорта.

Я не заметил, что TDD вообще делает неправильный выбор API.

Напротив, создавая четкую структуру, в первую очередь, API также становится более понятным, и многое другое очевидно для пользователей.

If your API is suffering due to internal requirements of your objects, that's what the facade pattern is for. Not all objects need to be public.

A lot of the pain points of TDD are, in fact, signs of pain points in the design. If it's hard to create a class because it requires 18 dependencies to be passed in, the fundamental problem is that the class has too many dependencies and is going to be quite brittle. It also probably does waaaaaay too much. The "TDD pain" in this case is a good thing, as it makes the other issues more obvious.

TDD является методом проектирования API. Каждый раз, когда вы пишете юнит-тест, вы либо создаете API в первый раз, либо используете ранее созданный API. Каждый из этих тестов позволяет "почувствовать", насколько легко или трудно использовать API. Каждый новый тест заставляет Вас рассматривать API с новой точки зрения. Вряд ли можно найти лучший способ разработать API, чем исчерпывающе использовать их так, как заставляет TDD.

Действительно, именно поэтому TDD рассматривается как design, а не как методика тестирования. Когда вы практикуете TDD, вы не проектируете свои API в вакууме. Вы разрабатываете их , используя их !

TDD не мешает хорошему API дизайну.

Издевательство мешает хорошему API дизайну.

Эти два понятия не являются синонимами - я самостоятельно начал использовать TDD до того, как другие написали об этом книги, просто потому, что это дает понять, являются ли требования тестируемыми, а дизайн отвечает требованию.

Однако я думаю, что насмешка - это плохо, потому что она влияет на дизайн и реализацию и вводит другие, искусственные требования. Оно также раскрывает внутреннюю сторону реализации, которой не должно быть, и делает тестирование хрупким. Оно проверяет, как что-то делается, а не то, что делается.

Как противостоять этому: Используйте TDD, но не издевайтесь.