• Упрощаем юнит-тесты с помощью связки AutoFixture и xUnit

    Все мы знаем, что юнит-тесты — это классно, что только коду, который так или иначе покрыт тестами, можно доверять и что если какой-нибудь неопытный senior developer старший программист что-нибудь сломает, тесты это сразу же покажут.

    Тем не менее, написание тестов сложно назвать увлекательным процессом. Инициализация тестовых данных, инициализация моков, создание объекта тестирования… Пока доберешься до вызова метода, который ты собственно хотел проверить, тестировать уже и не хочется ничего. Я конечно утрирую, юнит-тест по своей природе не должен брать на себя слишком много и содержать пару сотен десятков строк инициализации (хотя и такое бывает), однако писать один и тот же код быстро надоедает. И вот уже появляются фабрики тестовых объектов, иерархия базовых классов для тестов и прочие ООП примочки, призванные «упростить» создание теста. Приводит это как правило к тому, что шансов быстро понять, что же делает тест, не путешествуя по этим самым объектам, практически не остается.

    Собственно, инструмент, о котором я хочу рассказать, как раз и призван упростить, а в некоторых случаях и полностью убрать фазу инициализации или Arrange фазу теста.
    Читать дальше →
    • +14
    • 18.2k
    • 3
  • Юнит-тестирование для чайников

    • Tutorial
    Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

    Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

    We need to go deeper
  • Сделай свой AngularJS: Часть 1 — Scope и Digest

    • Translation
    • Tutorial
    Angular — зрелый и мощный JavaScript-фреймворк. Он довольно большой и основан на множестве новых концепций, которые необходимо освоить, чтобы работать с ним эффективно. Большинство разработчиков, знакомясь с Angular, сталкиваются с одними и теми же трудностями. Что конкретно делает функция digest? Какие существуют способы создания директив? Чем отличается сервис от провайдера?

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

    В этой серии статей я собираюсь воссоздать AngularJS с нуля. Мы сделаем это вместе шаг за шагом, в процессе чего, вы намного глубже поймете внутреннее устройство Angular.
    Сделаем Angular вместе
  • Введение в ReactiveUI: коллекции

    • Tutorial
    Привет, Хабр!

    Часть 1: Введение в ReactiveUI: прокачиваем свойства во ViewModel

    В предыдущей статье мы поговорили про свойства во ViewModel, и что мы можем с ними сделать, используя ReactiveUI. У нас получилось привести в порядок зависимости между свойствами и собрать в одном месте вьюмодели информацию о том, какие в ней есть зависимости между свойствами.
    В этот раз еще немного поговорим о свойствах, а затем перейдем к коллекциям. Попробуем понять, какие проблемы есть с обычными коллекциями, и зачем было создавать новые, с уведомлениями об изменениях. И, конечно, попробуем их использовать.
    Приступим
    • +10
    • 12.2k
    • 2
  • Введение в ReactiveUI: прокачиваем свойства во ViewModel

    В своих C# проектах при реализации GUI я часто использую фреймворк ReactiveUI.

    ReactiveUI — полноценный MVVM-фреймворк: bindings, routing, message bus, commands и прочие слова, которые есть в описании почти любого MVVM-фреймворка, есть и тут. Применяться он может практически везде, где есть .NET: WPF, Windows Forms, UWP, Windows Phone 8, Windows Store, Xamarin.

    Конечно, если у вас уже есть опыт работы с ним, то что-то новое для себя вы здесь вряд ли найдете. В этой статье мы познакомимся с его базовыми возможностями, касающимися работы со свойствами во ViewModel, а в будущем, надеюсь, доберемся и до других, более интересных и сложных фич.
    Поехали?
  • Reinforced.Typings — библиотека для автоматической генерации TypeScript-тайпингов и не только

    Я написал небольшую, но полезную библиотечку для любителей TypeScript и ASP.NET MVC. Очень хотелось бы про нее рассказать — возможно какому-то разработчику на вышеупомянутой комбинации технологий (а возможно и целой команде) она существенно облегчит жизнь. Писать полноценную документацию на английском пока что времени нет. К ней вообще нужно подходить осмысленно, с чувством, толком и расстановкой. Поэтому я решил написать статью на Хабрахабр, и вот прямо сейчас, под катом, я сделаю краткий обзор и покажу какую магию можно делать этой штукой. Добро пожаловать.
    Читать дальше →
  • Знакомство с внутренним устройством .NET Framework. Посмотрим, как CLR создаёт объекты

    • Translation
    Вниманию читателей «Хабрахабра» представляется перевод статьи Хану Коммалапати и Тома Кристиана об внутреннем устройстве .NET. Существует альтернативный вариант перевода на сайте Microsoft.

    В статье рассматривается:

    • Системный домен (SystemDomain), Домен общего доступа (SharedDomain) и домен по умолчанию (DefaultDomain)
    • Представление объекта и другие особенности организации памяти
    • Представление таблицы методов
    • Распределение методов

    Используемые технологии: .NET Framework, C#

    Содержание


    1. Домены создаваемые начальным загрузчиком
    2. Системный домен
    3. Домен общего доступа (разделяемый)
    4. Дефолтный домен
    5. Загрузчик куч
    6. Основы типов
    7. Экземпляр объекта
    8. Таблица методов
    9. Размер базового экземпляра
    10. Таблица слотов метода
    11. Описатель метода
    12. Карта таблиц виртуальных методов интерфейсов и карта интерфейса
    13. Виртуальное распределение
    14. Статические переменные
    15. EEClass
    16. Заключение

    Читать дальше →
    • +22
    • 47.9k
    • 5
  • PostgreSQL: Приемы на продакшене

      Можно прочитать много книг по базам данных, написать кучу приложений на аутсорс или для себя. Но при этом невозможно не наступить на грабли, при работе с действительно большими базами/таблицами особенно, когда downtime на большом проекте хочется свести к минимуму, а еще лучше совсем избежать. Вот здесь самые простые операции, как например изменение структуры таблицы может стать более сложной задачей. Наиболее интересные случаи, проблемы, грабли и их решения из личного опыта с которыми нам на проекте Pushwoosh пришлось столкнуться описаны под катом. В статье нет красивых картинок, зато есть много сухого текста.

      image
      Читать дальше →
    • Храним 300 миллионов объектов в CLR процессе

        Камень преткновения — GC


        Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

        Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

        Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

        Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
        Что же делать? Не хранить много объектов долго?

        Зачем


        Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

        Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.
        Читать дальше →
      • NFX — Ультраэффективная Бинарная Сериализация в CLR

          Требования


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

          • самозацикленные графы объектов (деревья с back-references)
          • массивы структур (value types)
          • классы/структуры с readonly полями
          • инстансы существующих .Net коллекций (Dictionary, List), которые внутренне используют custom-сериализацию
          • большое кол-во инстансов типов, специализированных для конкретной задачи


          Речь пойдёт о трёх аспектах, которые очень важны в распределённых кластерных системах:

          • скорость сериализации/десериализации
          • объём объектов в сериализированном виде
          • возможность использовать существующие объекты без надобности “украшения” этих объектов и их полей вспомогательными атрибутами для сериализации

          Читать дальше →
        • Подводные камни WPF

            Каждый, кто достаточно долгое время разрабатывал приложения с использованием WPF, наверное, замечал, что этот фреймворк далеко не так прост в использовании, как может показаться на первый взгляд. В этой статье я попытался собрать некоторые наиболее типовые проблемы и способы их решения.
            Читать дальше →