Как правильно дразнить и модульный тест
Это свойства объекта «window» в JavaScript, так же как документ является одним из свойств объекта window, который содержит объекты DOM.
Свойство Session Storage поддерживает отдельную область хранения для каждого заданного происхождения, доступный в течение сеанса страницы, т.е. пока браузер открыт, включая перезагрузку и восстановление страницы.
Локальное хранилище делает то же самое, но сохраняется, даже когда браузер закрыт и снова открыт.
Вы можете установить и получить сохраненные данные следующим образом:
sessionStorage.setItem('key', 'value');
var data = sessionStorage.getItem('key');
Аналогично для localStorage.
4 ответа
По сути, вы тестируете здесь то, что методы вызываются, а не работают ли они на самом деле. Это то, что издевательства должны делать. Вместо вызова метода, они просто проверяют, был ли вызван метод, и возвращают все, что есть в выражении Return (). Итак, в вашем утверждении здесь:
Assert.That(result, Is.False, "error message here");
Это утверждение ВСЕГДА будет успешным, потому что ваше ожидание ВСЕГДА вернет false, потому что оператор Return:
userRepo.Expect(repo => repo.CreateUser(theUser)).Return(false);
Я предполагаю, что это не ' Это полезно в этом случае.
Где насмешка полезна, когда вы хотите, например, сделать вызов базы данных где-то в вашем коде, но вы не хотите фактически вызывать базу данных. Вы хотите притвориться, что база данных была вызвана, но вы хотите настроить поддельные данные для ее возврата, а затем (вот важная часть) протестировать логику, которая делает что-то с поддельными данными, возвращенными вашей поддельной. В приведенных выше примерах вы пропускаете последний шаг. Представьте, что у вас есть метод, который отображает сообщение для пользователя, в котором говорится, был ли создан новый пользователь:
public string displayMessage(bool userWasCreated) {
if (userWasCreated)
return "User created successfully!";
return "User already exists";
}
тогда ваш тест будет
userRepo.Expect(repo => repo.CreateUser(theUser)).Return(false);
Assert.AreEqual("User already exists", displayMessage(userSvc.CreateUser(theUser)))
Теперь это имеет какое-то значение, потому что вы тестируете какое-то реальное поведение. Конечно, вы также можете просто проверить это напрямую, передав «true» или «false». Вам даже не нужно издеваться над этим тестом. Ожидания по тестированию - это хорошо, но я написал множество таких тестов и пришел к тому же выводу, к которому вы пришли - он просто не так полезен.
Короче говоря, насмешка полезна, когда вы хотите абстрагироваться от внешних факторов, таких как базы данных, вызовы веб-служб и т. Д., И ввести известные значения в этот момент. Но не всегда полезно тестировать макеты напрямую.
Вы правы: простота сервиса делает эти тесты неинтересными. Только когда Вы получаете больше бизнес-логики в сервисе, Вы получите значение от тестов.
Вы могли бы рассмотреть некоторые тесты как они:
CreateUser_fails_if_email_is_invalid()
CreateUser_fails_if_username_is_empty()
Другой комментарий: это похоже на запах кода, что Ваши методы возвращают булевские переменные для указания на успешность или неуспешность. У Вас могло бы быть серьезное основание сделать это, но обычно необходимо позволить исключениям распространить. Это также делает его тяжелее для записи хороших тестов, так как у Вас будут проблемы при обнаружении, перестал ли метод работать по "правильной причине", f.x. Вы мог бы записать CreateUser_fails_if_email_is_invalid () - тест как это:
[Test]
public void CreateUser_fails_if_email_is_invalid()
{
bool result = userSvc.CreateUser(userWithInvalidEmailAddress);
Assert.That(result, Is.False);
}
и это, вероятно, работало бы с Вашим существующим кодом. Используя TDD Red-Green-Refactor-cycle смягчил бы эту проблему, но будет еще лучше быть в состоянии на самом деле обнаружить, что метод перестал работать из-за недопустимой электронной почты, и не из-за другой проблемы.
Если Вы запишете свои тесты перед записью кода то Вы получите намного больше от Ваших модульных тестов. Одна из причин, что похоже на Ваши тесты, не стоит многого, то, что Вы не получаете значение наличия Вашего тестового диска дизайн. Запись Ваших тестов впоследствии является главным образом просто упражнением в наблюдении, если можно помнить все, что может пойти не так, как надо. Запись Ваших тестов сначала заставляет Вас думать о том, как Вы на самом деле реализовали бы функциональность.
Эти тесты не все это интересное, потому что функциональность, которая реализуется, является довольно основной. Путем Вы идете о насмешке, кажется довольно стандартным - дразнят вещи, класс под тестом зависит от, не класс под тестом. Тестируемость (или хороший смысл дизайна) уже привела Вас реализовывать интерфейсы и использовать внедрение зависимости для сокращения связи. Вы могли бы хотеть думать об изменении обработки ошибок, как другой предположили. Было бы хорошо знать, почему, если только улучшить качество Ваших тестов, CreateUser перестал работать, например. Вы могли сделать это за исключениями или за out параметр (который является, как MembershipProvider работает, если я помню правильно).
Вы сталкиваетесь с вопросом о «классическом» и «мокистском» подходах к тестированию. Или «проверка состояния» или «проверка поведения», как это описал Мартин Фаулер: http://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting
Еще один самый замечательный ресурс книга Джерарда Месароса "Тестовые шаблоны xUnit: рефакторинг тестового кода"