2011-01-13 2 views
1

Если у меня есть метод утилиты, такой как ниже, как я могу его протестировать? Похоже, если бы я хотел определить, что результат был правильным, мне пришлось бы построить код в методе тестирования? Я мог видеть, была ли условная логика, например, если входная строка пуста, возвращает null, но проверка правильного вывода кажется сложной.Утилиты для тестирования единицы измерения

public static string EncodeTo64(string input) 
{ 
    byte[] b = System.Text.ASCIIEncoding.ASCII.GetBytes(input); 
    string returnValue = System.Convert.ToBase64String(b); 
    return returnValue; 
} 
+2

«Похоже, что, если я хотел бы определить, что результат был правильным, мне нужно было бы создать код в методе тестирования »- есть школа TDD, в которой говорится, что вы должны делать именно это для ВСЕХ модульных тестов; напишите код в тесте, который дает желаемый результат, а затем реорганизуйте логику в свой метод. Это скорее инструмент обучения для этой концепции, но не менее важен, особенно в этом случае. – KeithS

ответ

5

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

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

1

Это зависит от того, что означает «правильность» этой функции для вас, разработчика. Я бы преобразовал известную строку в вывод, убедитесь, что это правильно в соответствии с любыми критериями для меня, а затем сравните, что результат функции соответствует результату, который я произвел. Что-то вроде этого:

const string expectedBase64String = "abc123$$%++"; 
const string testString = "Not the base 64 source of above"; 

Assert.AreEqual(expected, Utility.EncodeTo64(testString)); 

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

0

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

1

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

Это бы смысл для писать тесты, которые документируют, что делает метод, когда вы передаете его необычные входы: Null, string.Empty, строки с не-ASCII кодировок и т.д ..

+0

Конечно, вы должны проверить выход. У метода может быть ошибка, например, неправильная кодировка –

+2

@Rune FS. Я согласен с тем, что вы должны проверить, что происходит при неправильном кодировании (и даже упоминал это в моем ответе). Однако не следует писать модульные тесты для проверки поведения 'System.Convert'. –

+0

Согласитесь не тестировать ConvertToBase64, но вы пишете «вы бы вообще не тестировали вывод», с чем я не согласен, поскольку это говорит о том, что не тестировать вывод метода. У метода может быть ошибка, например: System.Text.ASCIIEncoding.Unicode.GetBytes (ввод), о которой вы не упоминаете в своем ответе –

Смежные вопросы