Модульный тест для метода, который изменяет состояние частного поля - PullRequest
2 голосов
/ 06 мая 2011

Итак, у меня есть следующая проблема (с использованием C #):

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

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

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

Не думаю, что у меня возникнут какие-либо проблемы с реализацией, но я пытаюсь написать модульные тесты для этого метода (с помощью MSTest) и не могу понять, как я могу правильно это проверить.

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

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

Какие-нибудь идеи или лучшие практики о том, как подойти к этому?

Ответы [ 2 ]

3 голосов
/ 09 мая 2011

Используйте PrivateObject.GetField(), чтобы получить окончательное состояние этого поля.( члены privateObject )

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

2 голосов
/ 06 мая 2011

Какое видимое изменение происходит при правильном копировании полей? Предположительно, это влияет на поведение объекта некоторым способом ... так что это идеальная вещь для тестирования.

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

...