Андрей Литвинов firestarter

Не работает, ведь, потому, что плохо написано. А вы, как заказчик, на этапе разработки первой фичи можете позаботиться о том, чтобы ее было достаточно просто поддерживать и расширять. Хотя про «Сделай по-быстрому, а потом зарефакторим» уже написано много.

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

Да, Yoga очень интересная модель, спасибо. Сейчас основной кандидат на покупку.

Меняется в полноэкранном режиме.

(нашел ответ ниже)

А какой ноут? Я тоже присматриваюсь к тач-дисплеям. Lenovo Switch, вроде, ничего так, но дисплей 12'' маловато, думаю.

плох разработчик, который ни разу его не читал

Чем плох?

Очень хотелось бы дать почитать эту статью на английском своей команде.

плакать и жевать кактус

Как жизненно.

Я обязательно еще ближе посмотрю на SpecFlow и NBehave. Сейчас у меня нет четкого понимания BDD и я не знаю BDD тесты должны быть модульными или интеграционными (возможно и то и то). Вопрос требует более глубокой проработки и я не хочу принимать опрометчивые решения.

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

Да чего я вам объясняю очевидные проблемы велосипедов.

Как минимум чтобы я прочитал и еще раз задумался. И, возможно, не только я. Спасибо.

Усложнять это решение у меня нет намерения. Благодаря комментариям к статья я узнал больше о BDD фреймворках и способах решить задачу похожим образом. Тем более атрибуты называются так же и если вдруг понадобиться более сложная функциональность перейти на SpecFlow, например не составит труда.

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

Вот вы же предложили распространить решение NuGet пакетом

Да, конечно. Для меня тесты в таком стиле читабельнее и удобнее. Без необходимости разбираться и работать с новыми фреймворками. Этот фактор может оказаться очень значимым в контексте проекта или команды.

И это уже проблема.

В чем вы видите проблему? Класс с минимальным количеством логики, который делает тесты понятнее. Да, я как раз и собираюсь использовать его в проекте. Для меня это сродни Extension методу для закрытого класса.

В общем очередной велосипед.

Да, конечно, я практически так и написал. Велосипеды создавать интересно ©

Я как раз и стараюсь создать и начать использовать DSL в проекте и двигаюсь в сторону DDD, но пока это все в зачаточном состоянии.

Чем плохи модульные тесты в BDD стиле?

При правильной организации модульных тестов given — в предыницализации теста, when — одна строчка, then — мясо теста.

Я так и написал, только не мясо а проверки (Assert).

Наверно у вас просто неправильные тесты — раз понадобился такой странный механизм.

Это неправильные пчелы и они дают неправильный мед

До этого использовал блок Arrange, в котором подготавливал данные для тестирование, блок Act и блок Assert где проверял результат теста. Все это происходило в одном методе — тесте. И когда инициализация занимает больше 15 строк кода читать такой тест становится неудобно. Но чем такие тесты неправильны?

Выглядит здорово.

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

Да, подход основан на спецификациях, поведении. Я когда первый раз увидел MSpec не сразу сообразил как он работает, но идея отличная =)

SpecFlow другой фреймворк и я его не пробовал. Мы используем NUnit в проекте и хочется использовать один фреймворк для тестов, тем более NUnit мне нравится. Плюс у Resharper нет нативной поддержки SpecFlow. Хотя NCrunch поддерживает его через интеграцию с NUnit, так что может и с Resharper будет работать. Стоит присмотреться? Чем он хорош?

Спасибо за ссылку. Посмотрел на NBehave — это довольно большой фреймворк с полноценной реализацией поведения, своим раннером и плюшками, интересно. У меня идея была использовать синтаксис NUnit, но вместо блоков Arrange, Act, Assert использовать методы, по названиям которых проще понять какое поведение моделируется.

Мы тоже используем MVC рядом c WebForms, но в одном проекте в студии. Трудностей не возникает, MVC маршрутизируется отдельно WebForms отдельно и друг другу практически не мешают. В некоторых случаях нужно рендерить MVC View внутри aspx странички с мастер страницей. Использую такой код:

<asp:Content ID="Content1" runat="server" ContentPlaceHolderID="content">
    <%{
          var helperFactory = new MvcHelperFactory(new HttpContextWrapper(Context));
          HtmlHelper htmlHelper = helperFactory.CreateHtmlHelper();
          MvcContent.Text = htmlHelper.Action("Index", "Home").ToString();
      }%>
    <asp:Literal ID="MvcContent" runat="server"></asp:Literal>
</asp:Content>

MvcHelperFactory это свой класс который просто создает HtmlHelper. При таком подходе выполняется полноценный процесс обработки запроса движком MVC с байндингами моделей и т.п. В сети встречаются разные варианты решения, этот мне показался самым удобным.

Анонимный объект и лямбда выражение. Я бы Action использовал вместо Function.

Это просто замечательная новость! Надеюсь скоро появятся сервисы с музыкой в лосслесс качестве.

Да, плагин — вариант. Но для этого нужен сервис, который будет вещать в лосслесс со своим плагином. Мне такие не встречались, но сам бы пользовался с удовольствием.

Я как-то тоже интересовался этим вопросом. Для того, чтобы стримить lossless по HTTP нужен кодек который будут поддерживать браузеры, но пока разработчикам браузеров это не интересно. Инфа примерно 1,5 года давности.

Да, я это и имел в виду, неправильно выразился.

Какое-то статическое свойство какого-то класса? А как его в таком случае фейкать при тестировании?

Чуток погуглив нашел вопрос на stackoverflow. Видимо, фейкать нужно как раз свойство DependencyInjector.Current.

Да, теперь понятнее, а то не складывалась картинка, не хватало пазла, спасибо =)

вынесите данные в сервис и обратитесь к нему через сервис-локатор

Я почитал немного про сервис-локаторы. Можно небольшой пример как передать атрибуту именно локатор, у которого он может получить сервис?

Я вижу проблему в том, что при каждом обращении к атрибуту объекта через рефлексию создается новый экземпляр атрибута, поэтому вариант с установкой локатора через сеттер свойства не подходит.

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

Я что-то упускаю или не правильно понял реализацию сервис-локатора?

зарегистрировать собственную фабрику валидаторов FV: FluentValidationModelValidatorProvider.Configure();

Упустил этот момент, спасибо.

рекомендую посмотреть, как DA обрабатывает такие ситуации

Не до конца понял какие именно ситуации. Можно ссылочку где это можно посмотреть?

когда выполняется валидатор, определенный атрибутом на классе

Для MVC при байндинге модели, так же как и DA.

почему в нем не следует задавать правила для отдельных свойств

Не совсем понял вопрос. Но столкнулся с ситацией когда определен DA атрибут [Required] и FV NotEmpty() при построении представления происходило исключение связанное с тем, что для свойства одно и тоже правило было задано несколько раз.

Понятнее? Нет, потому что мы перестаем видеть бизнес-правила.

В студии довольно просто перейти к определению класса атрибута и посмотреть бизнес-правила. Тут, наверное, кому как удобнее. Мне было сложно визуально выделять атрибуты валидиции, особенно условные с зависимостями на другие свойства. Они было громоздкие.

Для простых правил DA мне тоже отлично подходит.

Если в модели для каждого свойства заданы несколько атрибутов для валидации (обязательность, длина, регулярное выражение, какой-то кастомный, например) — модель превращается у «ужасного монстра». А если добавить еще и локализацию — то сложно будет разглядеть свойства под навешанными атрибутами.

При FV добавляется всего один атрибут класса и вся логика находится в нем. Модель становится намного легче и понятнее.

В статье я только поверхностно коснулся того, что такое FV.

По поводу тестирования атрибутов — это отельный вопрос. Мне нужно было для валидации получать данные из БД. Замокать логику доступа к данным в атрибуте в юнит тестах довольно сложно, потому что это метаданные класса, нельзя использовать наследование или заменить атрибут во время выполнения. С FV это делается очень просто.