Как делают меня файл сохранившего модульного теста к диску?

Старая почта, но вот шаг за шагом, которая работала для SQL Server 2014 под управлением Windows 7:

  • Панель управления ->
  • Система и безопасность - >
  • Администрирование ->
  • Службы ->
  • Дважды щелкните SQL Server (SQLEXPRESS) -> щелкните правой кнопкой мыши, Свойства
  • Выберите Вход в систему
  • Выберите «Локальная системная учетная запись» (по умолчанию была какая-то туповатая учетная запись Windows)
  • -> OK
  • щелкните правой кнопкой мыши, остановите
  • щелкните правой кнопкой мыши, Start

Voilá!

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

22
задан chester89 1 August 2010 в 11:16
поделиться

2 ответа

Мой подход к этому в значительной степени основан на книге Growing Object-Oriented Software Guided by Tests (GOOS), которую я только что прочитал, но это лучшее, что я знаю на сегодняшний день. А именно:

  • Создайте интерфейс, чтобы абстрагировать файловую систему от вашего кода. Подражайте ему там, где этот класс необходим как взаимодействующий/зависимый. Таким образом, ваши юнит-тесты будут быстрыми, а обратная связь - быстрой.
  • Создайте интеграционные тесты, которые проверяют фактическую реализацию интерфейса. Например, проверьте, что вызов Save() действительно сохраняет файл на диск и имеет содержимое записи (используйте эталонный файл или разберите его на несколько вещей, которые он должен содержать)
  • Создайте приемочный тест, который проверяет всю систему - от конца до конца. Здесь вы можете просто проверить, что файл создан - цель этого теста состоит в том, чтобы подтвердить, что реальная реализация подключена / подключена правильно.

Обновление для комментатора:

Если вы читаете структурированные данные (например, объекты Book) (если нет, замените string на IEnumerable)

interface BookRepository
{
  IEnumerable<Books> LoadFrom(string filePath);
  void SaveTo(string filePath, IEnumerable<Books> books);
}

Теперь вы можете использовать инъекцию конструктора для внедрения макета в класс клиента. Таким образом, модульные тесты клиентского класса работают быстро и не бьют по файловой системе. Они просто проверяют, что правильные методы вызываются на зависимостях (например, Load/Save)

var testSubject = new Client(new Mock<BookRepository>.Object);

Далее вам нужно создать реальную реализацию BookRepository, работающую с файлом (или Sql DB, если хотите). Никто другой не должен знать об этом. Напишите интеграционные тесты для FileBasedBookRepository (который реализует вышеуказанную роль) и проверьте, что вызов Load со ссылкой на файл дает нужные объекты, а вызов Save с известным списком сохраняет их на диск. Т.е. использует реальные файлы Эти тесты будут медленными, поэтому пометьте их тегом или перенесите в отдельный набор.

[TestFixture]
[Category("Integration - Slow")]
public class FileBasedBookRepository 
{
  [Test]
  public void CanLoadBooksFromFileOnDisk() {...}
  [Test]
  public void CanWriteBooksToFileOnDisk() {...}
}

Наконец, должен быть один/несколько приемочных тестов, которые проверяют Load и Save.

40
ответ дан 29 November 2019 в 04:17
поделиться

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

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

6
ответ дан 29 November 2019 в 04:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: