Модульное тестирование Application_Start

эта функция вызывается при первом посещении вашего сайта. повторное использование пула приложений приведет к его повторному запуску

В большинстве ситуаций это обработчик событий не имеет кода, так что не тратьте время на поиски бессмысленных цифр!

В типичном приложении ASP.NET MVC событие Application_Start часто используется для регистрации настраиваемых маршрутов. Вот хороший Почта, объясняющий, как проводить модульное тестирование ваших пользовательских маршрутов.

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

Кстати, я никогда не достигал 100% охвата нетривиальным приложением ... Обычно мы ориентируемся на 80% как «достаточно хорошо». Некоторые модули можно тестировать на 100%, но многие из них не практичны.

Я нашел, что лучший способ модульного тестирования материала в Global.asax - это убедиться, что все это находится в тестируемом статическом методе.

Затем передайте этому методу все, что ему нужно, из Global.asax.

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

public static void CheckSession(HttpSessionStateBase session)
{
...
}

Тогда ваше приложение Start будет просто таким:

protected void Application_Start(object sender, EventArgs e)
{
    CheckSession(new HttpSessionStateWrapper(Session));
} 

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

Тем не менее, это дает понять. Единственный код, который не будет рассмотрен, - это фактический однострочный вызов в Application_Start. Все остальное можно покрыть тестом с использованием Moq следующим образом:

var session = new Moq<HttpSessionStateBase>();
...Set Expectations...
Global.CheckSession(session.Object);
...Do Asserts...

Вы не добьетесь того 100% покрытия кода, которое ищете, но вы будете чертовски близко, и вы бы соответствовали «духу» закона TDD, если бы не совсем его буква :)

Некоторым организациям требуются эти бессмысленные числа, и у них возникают проблемы, не связанные с затратами. Для компаний, имеющих дело с простой информацией, «достаточно хорошо» недостаточно. У меня была точно такая же проблема, и, как и Клас Меллборн, мне нужно было достичь 100% (если не выше!) Следующее сработало для меня. Хотя я бы предпочел пометить его как «Исключить из покрытия кода».

public class Global : HttpApplication
{
    public override void Init()
    {
        AreaRegistration.RegisterAllAreas(); //will error out on app_start
        base.Init();
    }

    /// <summary>
    /// Application_Start method.
    /// </summary>
    /// <param name = "sender">The caller</param>
    /// <param name = "e">The event arguments</param>
    [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode", Justification = "KMM: This method is called dynamically by the framework.")]
    protected void Application_Start(object sender, EventArgs e)
    {
        var container = StructureMapRegistry.Initialize();
        GlobalConfiguration.Configuration.DependencyResolver = new StructureMapResolver(container);
        GlobalConfiguration.Configure(WebApiConfig.Register);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
    }
}

Тогда юнит-тест выглядел так:

 public class GlobalTest : Global
    {
        private HttpRequestMessage FakeRequest;

        DateTime? effectiveDate = DateTime.Now.AddYears(-4);
        private string policyNumber = "1234567890";

        [TestMethod]
        public void ApplicationStart()
        {
            var sender = new object();
            var e = new EventArgs();
            try
            {
                Application_Start(sender, e); // this will error b/c not fully loaded yet.
            }
            catch (InvalidOperationException)
            {
                Thread.Sleep(2000); // give the app time to launch

                Application_Start(sender, e);
            }
            Assert.IsTrue(true);
        }
    }

и, наконец, мне нужно было установить флаг в моем WebApiConfig, чтобы маршруты не регистрировались дважды.

 public static class WebApiConfig
    {
        private static bool isRegistered;
        /// <summary>
        /// Registers the configuration.
        /// </summary>
        /// <param name = "config">The Http Configuration.</param>
        public static void Register(HttpConfiguration config)
        {
            if (isRegistered)
            {
                return;
            }
            config.MapHttpAttributeRoutes();

Теперь, прежде чем ненавистники и пуристы начнут отмечать это, задача состоит в том, чтобы протестировать весь код. Лично я терпеть не могу модифицировать код для соответствия тестам. Это не то же самое, что сделать код тестируемым. Добавление флага isRegistered - это пример артефакта, необходимого для поддержки теста, требующего вызова app_start 2x. Это мелочь, и поскольку этот код вызывается только в app_start, я не собираюсь особо суетиться по этому поводу. Мне, безусловно, было бы интересно, что другие сделали в этом отношении.