Пример кода автоматического модульного теста

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

#include "samples/sampleA.h"

void main()
{
  SomeFunction();
}

затем после того, как вы сделаете сборку, запустите эти маленькие приложения, вам нужно убедиться, что они работают нормально. Но можете ли вы убедиться, что код работает нормально, не устраивая вечеринку с сервером NightlyBuild?

Лучшее решение: Зарегистрируйте вывод и попросите кого-нибудь взглянуть на него утром.

Еще лучшее решение: Регистрирует вывод и grep или что-то в этом роде, чтобы никто не смотрел на него, если он не сломан.

Лучшее решение: Найдите подходящий фреймворк для тестирования, надеюсь, что-нибудь со всеми прибамбасами, которые вы можете получить, чтобы он мог отправлять письма людям, если он сломан или что-то в этом роде. В нашем случае мы избегаем наворотов, вместо этого мы подключили USB-сирена полиции, который срабатывает, когда что-то ломается. Это довольно интересно!

Я сам этого не делал, но я видел, как об этом упоминалось в книгах прагматичных программистов. Если я не ошибаюсь, в книге «Прагматическое модульное тестирование на C# с помощью Nunit» упоминается, что они сделали это для книги. Возможно, они упомянули в одном из своих подкастов.

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

Я бы посоветовал использовать в вашем XML специальный фрагмент разметки, который гласит: «Возьмите образец кода отсюда». Это будет относиться к обычному файлу C#, который можно запустить с помощью модульных тестов. Если взять ваш пример, у вас может быть:

/// <summary>Summary here</summary>
/// <example>Here is an example
/// <code>!!sourcefile:SomeClassTest.cs#SomeFunction!!</code></example>
public void SomeFunction()

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

Придумывать собственную разметку, конечно, некрасиво, но она должна работать.

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

Да, Sandcastle поддерживает это, и здорово поддерживать правильность примеров. Вы можете указать на область кода следующим образом:

   /// <summary>
   /// Gizmo which can act as client or server.
   /// </summary>
   /// <example>
   /// The following example shows how to use the gizmo as a client:
   /// <code lang = "cs"
   ///    source = "..\gizmo.unittests\TestGizmo.cs"
   ///    region = "GizmoClientSample"/>
   /// </example>
   public class Gizmo

Затем вы можете использовать некоторый тестовый код в TestGizmo.cs в качестве примера, заключив его в область:

[Test]
public GizmoCanActAsClient()
{
   #region GizmoClientSample
   Gizmo gizmo = new Gizmo();
   gizmo.ActAsClient();
   #endregion
}

Предостережение: если вы переместите или переименуете тестовый файл, вы получите сообщение об этом только при попытке регенерировать документацию с помощью sandcastle.