Как я дразню/фальсифицирую объект сессии в Веб-формах ASP.NET?
Существует ли способ дразнить/фальсифицировать объект сессии в Веб-формах ASP.NET при создании модульных тестов?
Я в настоящее время храню пользовательские детали в переменной сеанса, к которой получает доступ моя бизнес-логика.
При тестировании моей бизнес-логики в изоляции сессия не доступна. Это, кажется, указывает на плохой дизайн (хотя я не уверен). Слой бизнес-логики должен получать доступ к переменным сеанса во-первых?
Если так, затем как я пошел бы о свопинге пользовательских деталей с поддельным объектом для тестирования?
4 ответа
В ASP.NET вы не можете создать тестовый двойной HttpSessionState, потому что он запечатан . Да, это плохой дизайн со стороны оригинальных разработчиков ASP.NET, но с этим ничего не поделаешь.
Это одна из многих причин, по которой TDD'ers и другие практикующие SOLID в значительной степени отказались от ASP.NET в пользу ASP.NET MVC и других, более тестируемых фреймворков. В ASP.NET MVC сеанс HTTP моделируется абстрактным классом HttpSessionStateBase.
Вы можете применить аналогичный подход и позволить вашим объектам работать над абстрактным сеансом, а затем обернуть реальный класс HttpSessionState, когда вы работаете в среде ASP.NET. В зависимости от обстоятельств, вы можете даже повторно использовать типы из System.Web.Abstractions, но если нет, вы можете определить свои собственные.
В любом случае, ваша бизнес-логика - это ваша Domain Model и она должна быть смоделирована независимо от какой-либо конкретной технологии выполнения, так что я бы сказал, что она не должна иметь доступа к объекту сеанса в первую очередь.
Если вам абсолютно необходимо использовать Test Doubles для модулей с HttpSessionState, это все еще возможно при использовании некоторых инвазивных динамических макетов, таких как TypeMock или Moles, то, как вы уже подумали, они несут в себе много недостатков (см. это сравнение динамических макетов).
.Ваши инстинкты верны... вы не должны получать доступ к частям ASP.NET фреймворка из вашей бизнес-логики. Сюда входит Session.
Чтобы ответить на свой первый вопрос, вы можете насмехаться над статическими классами, используя такой продукт, как Typemock Isolator, но вам будет лучше, если вы рефакторизуете свой код, чтобы обернуть доступ к Session в интерфейс (т.е. IHttpSession.) Затем вы можете насмехаться над IHttpSession.
.Одним из подходов является передача в ваш код выражения лямбда, которое принимает на вход строку (или какой-то другой объект) и использует ее для установки либо объекта Session, либо контейнера тестирования.
Однако, как уже говорили другие, хорошей идеей будет перенести доступ к объекту Session из вашей BLL.
.В веб-формах Asp.Net вы не можете избежать того, что фреймворк входит в ваш код со страниц aspx. Я согласен, что ваш бизнес-уровень не должен напрямую касаться специфических компонентов asp.net, но у вас должен быть контейнер для хранения модели, и сессия в asp.net - это хорошая область. Таким образом, одним из возможных подходов является создание ISessionManager с целью взаимодействия внутри вашего бизнес уровня. Затем, реализовать конкретный тип с помощью HttpSessionState ... btw, хорошим трюком является использование HttpContext.current.Session для реализации аксессуаров/приемников из HttpSessionState. Ваша следующая задача будет заключаться в том, как соединить все это вместе.