Можно ли проверить локальное значение с помощью теста junit? - PullRequest
3 голосов
/ 11 октября 2011

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

Ответы [ 3 ]

6 голосов
/ 11 октября 2011

Добавление точки останова на самом деле не является модульным тестированием и фактически вовсе не тестированием.Вы можете назвать это проверкой, но такой вещи, как Check Driven Development, не существует.

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

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

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

2 голосов
/ 11 октября 2011

Ваш вопрос приводит к объяснению D в TDD.Особенно, когда вы используете TDD для обозначения «Тест-управляемого проекта» (хотя некоторые люди предпочитают фразу «Тест-управляемого проекта»).

Как указывает @Shahzeb, возможно, ваш метод слишком длинный и должен быть разбит на два метода, один из которых выдает промежуточное значение, а другой - принимает его в качестве входных данных.Наша склонность думать о коде подобным образом буквально определяется тестами. Дизайн нашего кода лучше, потому что мы разделяем проблемы, чтобы начать их тестировать.Итак, вы задаете хороший вопрос (чей короткий и простой ответ - «Нет»), и именно такие вопросы позволяют TDD улучшить наш дизайн.

1 голос
/ 14 октября 2011

Идея состоит в том, что вы вообще не тестируете приватное (промежуточное) значение, потому что оно не важно внешне (именно поэтому вы мудро держите его в секрете.) Закрытое значение представляет собой некоторое состояние в вашем объекте, которое вы установилитеперь с намерением, что это повлияет на будущие вызовы к вашему общедоступному интерфейсу, верно?Так что поменяйте один тест, чтобы сделать два звонка.Пусть первый вызов сделает все, что ему нужно, чтобы установить состояние так, как вы думаете, а затем сделайте второй вызов и увидите, что он получился таким, каким вы ожидаете, когда эта переменная установлена.Если он действительно закрытый, для модульного теста не имеет значения, какова его ценность - только то, что он правильно дает желаемые результаты в нужное время.Но это предложение сопровождается предупреждением: оно проникает в ту область, где вы можете попросить, чтобы юнит-тест выполнил нечто большее, чем тестирование юнитом.

Еще одно наблюдение: вы говорите, что ваш метод «не может быть разделен», но не предлагаете объяснения, почему.Если вы не можете изменить дизайн, это больше похоже на то, что вы пытаетесь втиснуть модульный тест в унаследованный код, а не выполнять тестовую разработку.Это совершенно нормально, вам не нужно отказываться от TDD, но, возможно, есть и другие подходы, которые следует учитывать.После того, как вы пройдете тестирование, в TDD это часть, где вы должны немного реорганизовать метод.Тот факт, что вы говорите о промежуточном значении, говорит о том, что ваш метод несет слишком большую ответственность.Попробуйте использовать метод извлечения для инкапсуляции более кратких частей функциональности в меньшие, тестируемые методы обслуживания.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...