Должен ли я тестировать общедоступные интерфейсы только в BDD?(в общем и конкретно в Ruby)

Question

Я читаю (все еще бета) книгу rspec от prag progs , так как меня интересует поведенческое тестирование объектов. Исходя из того, что я почерпнул до сих пор (предостережение: после прочтения только в течение 30 минут), основная идея заключается в том, что я хочу, чтобы мой объект вел себя так, как ожидалось, «внешне», то есть при выводе и по отношению к другим объектам.

Правда ли тогда, что я должен просто быть черным ящиком, тестирующим мой объект, чтобы обеспечить надлежащий вывод / взаимодействие с другими объектами?

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

Полагаю, этот вопрос может быть применим ко всем типам тестирования? Я все еще довольно плохо знаком с TDD и BDD.

Answer 1

Если вы хотите лучше понять BDD, попробуйте подумать об этом, не используя слово «тест».

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

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

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

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

Надеюсь, это поможет!

Answer 2

Я думаю, что здесь есть две проблемы.

Одним из них является то, что с точки зрения BDD вы обычно проводите тестирование на более высоком уровне, чем с точки зрения TDD. Таким образом, ваши тесты BDD подтвердят большую функциональность, чем ваши тесты TDD, и всегда должны быть тестами «черного ящика».

Во-вторых, если вы чувствуете необходимость тестировать частные методы, даже на уровне модульного тестирования, это может быть запахом кода, поскольку ваш код нарушает Принцип единой ответственности и должны быть реорганизованы так, чтобы методы, о которых вы заботитесь, могли быть протестированы как общедоступные методы другого класса. Майкл Фезерс выступил с интересной лекцией об этом, недавно названном « Глубокая синергия между тестируемостью и хорошим дизайном ».

Answer 3

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