Kroniak .NET Blog

ASP.NET Core 5 Kubernetes Application

Nikolay Molchanov — Wed, 20 Jan 2021 18:39:55 GMT

Хорошие basewords для заголовка? Все самое современное. Читайте ниже, все будет.

C мая 2020 года команда JugRu создает свою, как мы называем "платформу" дистрибуции видео контента.

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

Моя основа для принятия решения - принцип разумной достаточности и практичности каждого решения.

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

В течение года нашей командой создано множество сервисов и инфраструктурных решений, начиная с продакшена видео, до SSO JWT авторизации и MMO игры, которые работают в комплексе и по отдельности друг от друга.

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

Вы можете посмотреть видео-интервью о первом online конференционном периоде.

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

ASP.NET Core 5 Kubernetes Application

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

Список тем

Общая архитектура современного web приложения
Балансировка web приложений
.NET Docker support
ASP.NET Core WebAPI - развертывание в k8s
GitLab CI для поддержки развертывания в k8s
.NET Core Logging вместе с k8s и ELK stack
.NET Core Real Monitoring - ELK APM
.NET Core Real Monitoring - Prometheus
Real life Cross Domain JWT SSO
ASP.NET Core JWT Authorization
.NET Core Distributed Cache - Redis Stack
.NET Core SignalR real user interaction
.NET Integration Testing

Это не полный исчерпывающий список тем, которыми я хотел бы поделиться.

На первое время я выбрал самые важные, и я постарась сосредоточиться на практической части освещения темы.

Следите за новостями!

Мутационный анализ - обновление 2021 - Часть 2

Nikolay Molchanov — Tue, 16 Mar 2021 13:44:28 GMT

TLDR; применяй сразу тут и примеры запуска на github

Пролог

Эта статья является прообразом доклада на Dotnext 2019, где я рассказал о применении подхода мутационного тестирования в проектах на .NET Core.

Доклад вызвал неоднозначную реакцию, от "Зачем это необходимо?" до "Как я жил без этого раньше".

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

В предыдущей статье мы рассмотрели первую часть - вводную в теорию мутационного анализа.

Теперь мы разберем сами мутации, которые могут быть применены к вашему коду.

О чем пойдет разговор?

Часть 1

тестирование и для чего применять еще один вид
про принцип мутационного тестирования и анализа

Часть 2 - вы читаете эту часть

виды мутаций

Часть 3

как применить в .NET
когда использовать мутационное тестирование и как подготовится

Какие мутации могут быть в программном обеспечении

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

Большинство этих мутаций до тестов никогда не дойдут, так как сработает первая защита - проверка типов и компиляция.‌‌ Остальные мутации будут применены.

Типы мутаций

1. ООП Мутации в зависимости от языка и его реализации‌‌

Мутации модификаторов доступа‌‌
Мутации наследования - удаление указателей на классы, удаление override методов, удаление вызова base или super, удаление вызова родительского конструктора‌‌
Полиморфные мутации, например, изменения конкретного класса реализации интерфейса в коде
Мутации перегрузки методов и их аргументов‌‌
Общие мутации - удаление this, передача параметров по ссылке или по значению

‌‌2. Общие мутации‌

Арифметические операции‌‌
Мутации сравнения‌‌
Мутации логических операторов‌‌
Мутации bool типа‌‌
Мутации присвоения и арифметические‌‌
Унарные операции‌‌
Строковые мутации‌‌
Мутации массивов и списков‌‌

3. Специфические мутации для языка и библиотек - LINQ мутации

Теперь представьте, что этот массив мутаций будет применен к вашему коду. Вы еще точно уверены, что ваши тесты упадут и мутации будут убиты?

Статистика

Количество общих мутаций зависит от объема кода, для примера приведу статистику из двух библиотек, до того как применить мутационное тестирование и после.

Flurl, 9000 строк, покрытие 85%, 300 тестов, 363 мутантов, 43 сек выполнение тестов, 30 минут выполнение прогона мутаций.

Flurl Url Builder, 108 мутаций, изначально выжило 11 штук, рефакторингом доведено до 0, время прогона 7 минут, найдено критичных мутаций 2.

Flurl Http, 255 мутаций, 40 выжило, после рефакторинга осталось 2 эквивалентные.

Ecwid Client, 5000 строк, покрытие 90%, 200 тестов, 16 секунд выполняются тесты, 300 мутантов, 15 минут прогон тестов со всеми мутациями, изначально выжило 70, после рефакторинга выжило 10. Найдены 4 критичные ошибки.

Итоговая статистика получилась такая:

Примерно 10% мутаций будет в мертвом коде, который необходимо или удалить или написать на него тесты, если вы считаете что код может понадобиться, например, в случае публичной библиотеки.
Примерно 50% выживших мутаций укажут вам на недостаточное качество тестов.
Остальные мутации относятся к эквивалентным.

Распространенные примеры выживших мутаций и их влияние на тесты и на код

Теперь рассмотрим наиболее часто встречаемые примеры выживших мутаций.

Тут необходимо сказать, что вообще бороться с мутантами можно 2 способами - честным и нечестным:

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

Строковая мутация

Вы всегда проверяйте все ошибки, которые возвращаются на их корректность? И в разных локалях? А вы проверяете все строковые значения получаемого объекта?‌‌ Если нет то это прямая дорога получить на главной странице сайта или в мобильном приложении текст внутренней ошибки со stacktrace. Часто это ведет к репутационным потерям компании.

Самая распространенная выжившая мутация - строковая. Кол-во строк, которые курсируют из метода в метод, из exception в exception - очень велико.

Давайте рассмотрим пример 1

private bool ExceptionMethod(int a) {
 if (a < 0)
   throw new ArgumentException("USER_DB is not path pattern uiier_ksks", "user-name");

 ...

 return true;
}

public string LibraryMethod(int a) {
 try {
   if (ExceptionMethod(a)) return "Successfully";
 }
 catch (ArgumentException e) {
   throw new Exception("Something happened", e);
 }
 return null;
}

[Fact]
public void LibraryMethod_NegativeData_ThrowException() {
 // Act
 var ex = Assert.Throws<Exception>(() => SampleClass.LibraryMethod(-1));
 // Assert
 Assert.Equal("Something happened", ex.Message);
}

Что тут забыли? Если мы что то не проверяем, то мы это не контролируем.

[Fact]
public void LibraryMethod_NegativeData_ThrowException() {
  // Act
  var ex = Assert.Throws<Exception>(() => SampleClass.LibraryMethod(-1));
  // Assert

  Assert.Equal("Something happened", ex.Message);
  Assert.Equal("USER_DB is not path pattern uiier_ksks\nParameter name: user-name", ex.InnerException.Message);
}

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

Пример 2.

В Ecwid CLI был найден баг, при котором сервис не мог сконфигурироваться, когда один из токенов был невалидный. Тесты были написаны, exception возникал правильный, но не проверялись тексты ошибок - тесты были написаны неверно и выявился интересный баг.

[Fact]
public void Credentials_Fail() {
  Assert.Throws<Exception>(() => new Ecwid(0, Token, Token));

  Assert.Throws<Exception>(() => new Ecwid(ShopId));

  Assert.Throws<Exception>(() => new Ecwid(ShopId, " ", Token));

  Assert.Throws<Exception>(() => new Ecwid(ShopId, Token, " "));
}

Мутация границ и мутация операций сравнения

Рассмотрим пример

public string Encode(string s, ...) {
  if (string.IsNullOrEmpty(s)) return s;

  if (s.Length > MAX_URL_LENGTH) {
    ...
  }
  ...
}

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

В этом примере, мы проверили граничные условия, но не проверили средний вариант. Обычно тестируются негативные варианты. Не надо забывать и о положительных сценариях.

public Builder Limit(this Builder query, int limit) {
  if (limit <= 0)
    throw new ArgumentException("Limit must be greater than 0", nameof(limit));

  if (limit > 99) limit = 100;

  query.AddOrUpdate("limit", limit);
  return query;
}

Вот еще распространенный пример мутации операции сравнения

public void Some<T>(object arg, IEnumerable<T> list) {
  ...
  var out = new List<T>();
  ...

  if (out.Count > 0) {
    ...
  }
  ...
}

Мутируем оператор сравнения.

Тут мы можем применить второй способ ухода от мутации - вынесение ее за наш код.

public void Some<T>(object arg, IEnumerable<T> list) {
  ...
  var out = new List<T>();
  ...

  if (out.Any()) { // FirstOrDefault() != null
    ...
  }
  ...
}

LINQ мутации

В LINQ мутациях распространенной считается замена First на Last, Any на All, FirstOrDefault на Default.

Рассмотрим пример

public T GetValue(int field) {
  var values = await GetValues(new {field});

  return values.FirstOrDefault();
}

[Fact]
public void GetValue_ReturnCorrectData() {
  //... mock data
  var result = await client.GetValue("some data");

  Assert.Equal("some data", result.ValueNumber);
  //... some other assertion
}

Тест корректен, данные входные тоже. Применяется мутация FirstOrDefault на LastOrDefault.

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

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

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

Кстати, про сортировки, настоятельно прошу тестировать ваше приложение, даже unit тестами именно в том окружении, где ПО будет работать.

Если вы хотите деплоить в docker, то тесты необходимо запускать там же.

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

Примеры эквивалентных мутаций и способы ухода от них

Самые сложные мутации - это эквивалентные, те, которые не могут быть убитыми никакими тестами.

Самый простой пример - это условие выхода из цикла:

int index = 0;
while (...) {
  // …;
  index++;
  if (index == 10) { // mutate to >=
    break;
  }
}

Такие простые мутанты вычищаются как эквивалентные еще на этапе подготовки мутантов библиотеками мутационного тестирования.

А есть такие мутации:

public void Remove(SomeType<T> container, T data) {
  if (data == null) return;

  if (container.All(c => c.SomeField != data.SomeField)) return;

  container.Values.Remove(data); // очень много связанной логики и т.п.
}

[Fact]
public void Remove_NotExist_NotRemoved() {
  // Arrange
  var expected = container.Values.Count;
  var data = new Value();

  // Act
  TRepository.Remove(container, data);

  // Assert
  Assert.Equal(expected, container.Values.Count);
}

В чем проблема? Дело в том, что код проверки container.All(c => c.SomeField != data.SomeField) бессмысленный. Даже если условие не выполнится, то удаление произойдет.

Решение первое - удалить проверку вообще.

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

[Fact]
public void Remove_Exist_Removed() {
  // Arrange
  var expected = container.Values.Count;
  var data = container.Values.Get(1);

  // Act
  TRepository.Remove(container, data);

  // Assert
  Assert.Equal(expected - 1, container.Values.Count);
}

Это тест на удаление уже существующего элемента. Он работает, и мутация выжила. Рефакторим.

public void Remove(SomeType<T> container, T data) {
  if (data == null) return;

  var deleteT = container.FirstOrDefault(c => c.SomeField == data.SomeField);
  if (deleteT == null) return;

  container.Values.Remove(deleteT); // очень много связанной логики и т.п.
}

[Fact]
public void Remove_Exist_Removed() {
  // Arrange
  var expected = container.Values.Count;
  var data = container.Values.Get(1);

  // Act
  TRepository.Remove(container, data);

  // Assert
  Assert.Equal(expected - 1, container.Values.Count);
}

[Fact]
public void Remove_NotExist_NotRemoved() {
  // Arrange
  var expected = container.Values.Count;
  var data = new Value();

  // Act
  TRepository.Remove(container, data);

  // Assert
  Assert.Equal(expected, container.Values.Count);
}

Осталось только немного изменить тест с существующим элементом

public void Remove(SomeType<T> container, T data) {
  if (data == null) return;

  var deleteT = container.FirstOrDefault(c => c.SomeField == data.SomeField);
  if (deleteT == null) return;

  container.Values.Remove(deleteT); // очень много связанной логики и т.п.
}

[Fact]
public void Remove_Exist_Removed() {
  // Arrange
  var expected = container.Values.Count;
  var someField = container.Values.Get(1).SomeField;
  var data = new Value(someField);

  // Act
  TRepository.Remove(container, data);

  // Assert
  Assert.Equal(expected - 1, container.Values.Count);
}

Все, мы убили мутации, отрефакторили приложение и все хорошо? Или нет?‌‌Нам добавилась еще одна мутация эквивалентная. Какая? SingleOrDefault вместо‌ ‌FirstOrDefault.

Мы совсем не подумали, что бы будем делать, если у нас в контейнере несколько объектов на удаление. Рефакторим.

public void Remove(SomeType<T> container, T data) {
  if (data == null) return;

  var deleteT = container.SingleOrDefault(c => c.SomeField == data.SomeField);
  if (deleteT == null) return;

  container.Values.Remove(deleteT); // очень много связанной логики и т.п.
}

[Fact]
public void Remove_ExistDouble_ThrowsException() {
  // Arrange
  var expected = container.Values.Count;
  var someField = container.Values.Get(1).SomeField;
  var data = new Value(someField);

  // Act
  Assert.Throws<InvalidOperationException>(() => _TRepository.Remove(container, data));


  // Assert
  Assert.Equal(expected, container.Values.Count);
}

Теперь все отлично. А могли просто удалить строку, чтобы избавится от эквивалентной мутации.

В идеале работа с каждой эквивалентной мутацией заканчивается рефакторингом кода и выявлением неочевидных с точки зрения логики мест в коде.

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

Как пример приведу алгоритмы, основанные на генерации данных.

У вас есть один алгоритм генерации данных, и второй - алгоритм проверки данных на валидность.

Вы генерируете данные, например номера банковских карт или карт лояльности, потом проверяете их своим же валидатором.

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

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

Эпилог

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

Продолжение о применении в .NETCore в следующей части...

Ну а если вы любите больше смотреть, чем читать - версия конца 2019 года

Kubernetes Cheat Sheet

Nikolay Molchanov — Mon, 15 Mar 2021 15:41:53 GMT

А вы знали, что существует такая замечательная страница для тех, кто пользуется kubectl, где перечислены все самые длинные замысловатые команды, которые никогда не запомнишь?

Были ли у вас случаи гугления, когда необходимо увеличить кол-во реплик в deployment? Или применить патч?

Например заменить image в pod?

kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

Можете идти сразу сюда https://kubernetes.io/docs/reference/kubectl/cheatsheet/

Наслаждайтесь!

Photo by Dominik Lückmann / Unsplash

Мутационный анализ - обновление 2021 - Часть 1

Nikolay Molchanov — Mon, 15 Mar 2021 09:46:43 GMT

TLDR; применяй сразу тут и примеры запуска на github

Пролог

Доклад вызвал неоднозначную реакцию, от "Зачем это необходимо?" до "Как я жил без этого раньше".

Я являюсь мейтейнером одной популярной библиотеки Flurl для работы с HttpClient в виде builder. Она позволяет легко и просто составлять запрос к API.

Эта библиотека вдохновлена принципом TDD, kill фичей этой библиотеки является способность прозрачно тестировать ваши сервисы и ПО, когда они обращаются через http во внешний мир.

И библиотека на основе Flurl, которую я разрабатываю, Ecwid CLI - это тоже вдохновленный принципам TDD клиент к хранилищу данных для интернет магазинов, построенный на паттерне builder.

Примеры мутаций я буду давать на основе опыта внедрения для этих двух библиотек.

О чем пойдет речь?

Часть 1 - вы читаете эту часть

тестирование и для чего применять еще один вид
про принцип мутационного тестирования и анализа

Часть 2

виды мутаций

Часть 3

как применить в .NET
когда использовать мутационное тестирование и как подготовится

Тестирование

Видов тестирования очень много и каждый разработчик сталкивается с ними каждый день.

В своей практике разработчики встречаются с ручным функциональным тестированием (вы это это делаете постоянно, когда вносите исправление), с автоматизированным тестированием изолированных частей (unit тестирование), с автоматическим интеграционным тестированием или UI тестированием.

Для чего нам необходим еще один вид тестирования? Мы не тестировщики и писать тесты, как разработчики, особо не любим.

Вопрос к вам? А кто из вас перфекционист? А кто уверен в своих тестах на все 100 процентов? Что бы прям "зуб поставить", что они словят именно то, на что рассчитаны?

А есть ли у вас покрытие тестами более 70%?

А у кого ошибки в ПО повлияют на деньги клиентов, репутацию вашей компании или, не дай бог, жизнь и здоровье людей?

Для компаний и проектов с такими высокими рисками очень важно тестирование с покрытием на всей пирамиде тестирования близким к 100%, потому что другим способом проверить соответствие требованиям не можем. Или можем?‌‌

Есть один способ - это тестирование на выбранной группе лиц, например, анонимное тестирование медикаментов на группе беременных женщин по всему миру. Кто в здравом уме согласится сделать это добровольно? А если не сказать и опросить постфактум применения?

Хотели бы вы, например, поездить на Тесле, когда Илон Маск вам выкатит апдейт, который будет чуть чуть недостетирован? Или тестирование плохо кончились?

У кого нет покрытия в 70% знайте, - или ваш бизнес камикадзе или вы камикадзе. Тут, конечно, все грешные, и проблемы с написанием тестов и полноценным тестированием есть в больших компаниях. Редко какой бизнес готов ждать.

Самая частая причина не написания тестов - это отсутствие времени, выделенного на это.

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

У компании Oracle в ее главном продукте Oracle RDBMS написано порядка 40 тысяч автотестов, они прогоняются на большом кластере несколько часов и только они позволяют вносить исправления и доработки в код и сделать так, чтобы программный продукт не растекался как теплое желе при изменениях.

Про цель тестирования

Так зачем нам нужно во всех случаях тестирование как таковое?

Ради красивых цифр в code coverage? Ради бейджика, что вы умеете их разрабатывать? Для строчки в резюме “Пишу код на TDD”?

Нет

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

Так как же можно протестировать или валидировать тесты? Откуда вы знаете что они написаны корректно и действительно помогают вам добиться устойчивости вашего ПО?

Вы можете проводить code-review кода тестов, посчитать code-coverage для понимания какие участки кода покрыты тестами, вы можете запускать много раз тесты в разных окружениях, в pipeline и без него, при каждом билде, вы можете отдать ревью тестов на аудит, но в конечном итоге вы будете ориентироваться на мнение человека, а люди ошибаются или невнимательны. И все эти мероприятия полностью не покажут качество ваших тестов.

Нет других способов автоматизированно проверить ваши тесты на профпригодность. Кроме как… сломать их!

Вопрос к вам? Кто может дать гарантию того, что вы откроете в редакторе ваш код, внесете в него ошибку и ваши тесты гарантированно упадут?

Единственная возможность проверить вашу систему тестов до продакшена или до того как руки аутсорсеров в него внесут изменения - это внести в нее ошибку! Намеренно и специально. И посмотреть, что получится. Этим и занимается мутационное тестирование.

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

Парадигмы TDD-BDD и MDD

Существуют практики по разработке и по написанию тестов, которые вам хорошо известны - это TDD и BDD, разработка через тестирование и разработка на основе поведения пользователя.

Мутационное тестирование и разработку на основе мутаций давайте обзовем MDD - Mutation Driven Development. Оно пронизывает все слои тестирования и проверяет целиком систему на устойчивость.

Внимание ! Так же MDD можно описать как Main Depression Disaster, что означает основное депрессивное расстройство личности - это именно то, что вас ждет, когда вы увидите, что те тесты, которые вы долго и мучительно писали, причесывали, разбивали на группы и создавали тест кейсы, никуда не годятся. Первая мысль будет - ну его… С этой депрессией необходимо бороться на практике и на этапе написания кода.

Справившись с депрессией, MDD будет для вас хорошей практикой написания кода и тестов с точки зрения применимости к ним разнообразных мутаций еще до запуска самого мутационного тестирования, оно меняет сознание разработчика так же как TDD и BDD.

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

Исторический контекст и определение мутационного тестирования

Мутационное тестирование - это преднамеренное внесение в код специальных изменений - мутаций с целью проверки программного обеспечения.

Мутационный анализ появился как термин в 1971 году и был впервые применен на практике в 80тых. Основная сложность его применений полномасштабно, как и вообще всеобъемлющего тестирования - это стоимость. Мутационное тестирование требовательно к ресурсам и требует от разработчиков много времени для разбора мутаций и анализа влияния их на конечный результат.

ПО может сопротивляться изменениям двумя способами:

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

второе - это тесты на разных уровнях, которые проверяют соответствует ли ПО тем требованиям, которые к нему предъявляют и, если соответствия нет, система проверки должна говорить - нет.

Вопрос к вам? Как вы думаете какой тест лучше зеленый или красный?
Лучше красный, он или неверно написан или словил то, для чего был написан. В зеленый тест вы смотреть не будете никогда. Неважно работает корректно он или нет.

Все на деле просто: вы внесли ошибку, прогнали все тесты, тесты упали - отлично! Система отреагировала правильно.

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

И хорошо если, просто очередной котик на сайте не покажется пользователю.

В итоге мутант может быть убит упавшим тестом - это убитый мутант или ни один тест не среагировал на него - это выживший мутант.

Другим языком убитая мутация это такое условие:

Убитая мутация М - такая мутация, для которой существует тест t из набора тестов Т, для которого результат выполнения на модифицированном мутацией М коде не равен начальному результату на немодифицированном коде.

Разберем самый простой пример

bool Method(bool a, bool b) {
  if (a && b) { // mutate to ||
    return true;
  } else {
    return false;
  }
}

[Fact]
[InlineData(false, false)]
void Method_ReturnFalse(bool a, bool b) {
  // Act
  var result = Method(a, b);

  // Assert
  Assert.False(result);
}

Мы мутируем && оператор.

Мутант выживет или нет?

Для тогда что бы тест убил мутанта должны быть соблюдены следующие условия:

Тест должен достигнуть кода, то есть покрытие этих строк должно быть 100% - Покрытие
Входные данные для теста должны быть полными, чтобы мутант был убит - проверяются все граничные условия - Тестовые данные
Значение выходных параметров должно влиять на тесты и проверяться в тестах - Достаточная Ассертированность

Вот 3 условия при котором будет убит мутант.

int Method(bool a, bool b) {
  int c;
  if (a && b) { // mutate to ||
    c = 1;
  } else {
    c = 0;
  }
  return c;
}

[Fact]
[InlineData(false, false)]
[InlineData(true, false)]
[InlineData(false, true)]
void Method_ReturnFalse(bool a, bool b) {
  // Act
  var result = Method(a, b);

  // Assert
  Assert.False(result);
}

Общая модель мутационного тестирования

Как работают системы, которые занимаются мутационным тестированием?

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

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

После этого ваш код собирается со всеми мутациями N раз и результат сборки подмешивается в набор тестов.

Запускаются тесты и падают или не падают.

После этого идет сбор статистики, ее выдача в виде, который может проанализировать разработчик.

Продолжение в следующей части...

Литература

Ну а если вы любите больше смотреть, чем читать - версия конца 2019 года

Сборка React компонента как npm пакет

Nikolay Molchanov — Sun, 14 Mar 2021 09:54:06 GMT

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

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

Недавно я столкнулся с задачей выделения в библиотеку целого большого модуля на React\Typescript - игрового фронтенда game.jugru.org. Модуль переиспользуется в трех различных приложениях.

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

 {
 	"dependencies": 
    {
        "@inlet/react-pixi": "^5.1.4",
        "@microsoft/signalr": "^5.0.2",
        "evergreen-ui": "^5.1.2",
        "mobx": "^6.0.0",
        "pixi.js-legacy": "^5.3.7",
        "react": "^16.13.1",
        "react-dom": "^16.13.1",
    }
}

Готового решения, как в Angular проектах, я не нашел и поэтому решил завелосипедить самостоятельно.

С чего начать?

Начать стоит с формирования репозитория, в котором будет располагаться сама библиотека, и сразу в нем же example проект, который даст отлаживать готовое решение и собственно вести разработку с hot reload, проверкой синтаксиса и прочим.

Исторически я использую CRA почти с момента его первой публикации. Он позволяет решать многие задачи, абстрагируясь от конфигурации Webpack.

Я разбиваю проекты по принципу feature based modules.

npm package folder structure

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

В каталоге example находится входная точка и все содержимое CRA обертки для разработки.

Основный модулем для экспорта пакета является файл index.tsx.

import ReactDOM from "react-dom";
import React from "react";

import GameApplication, { PopupCallbackData } from "./game-engine/GameApplication";
import GameAdminApplication from "./game-engine-admin/GameAdminApplication";
import { DemoApplication } from "./example";
import { isExampleRunning } from "./example/config/config";
import { AuthOptions, TokenRights } from "./game-engine-admin/config";

export { GameApplication, GameAdminApplication };
export type { PopupCallbackData, AuthOptions, TokenRights }

if (isExampleRunning) {
    ReactDOM.render(<DemoApplication/>, document.getElementById('root'));
}

Мы реэкспортируем типы, которые будут основой типов пакета, и одновременно не позволяем экспортироваться example приложению в пакет за счет пробрасывания флага запуска isExampleRunning, который зависит от ENV переменных заданных при запуске.

Typescript самостоятельно построит d.ts файлы для описания типов приложения.

Осталось собрать сам пакет.

Сборка пакета

Существует много способов собрать typescript приложение, начиная от простой транспиляции компилятором TS его в javascript ES5 или ES6, заканчивая сборщиками webpack и rollup.

Я выбрал сборщик, так как помимо кода приложения, необходимо экспортировать изображения, транспилировать sass модули в css и сделать из этого один бандл.

А конкретно rollup, так как он показался мне понятнее для сборки пакета, поддерживает treeshaking, и проще в настройке.

Rollup is a module bundler for JavaScript which compiles small pieces of code into something larger and more complex, such as a library or application. It uses the new standardized format for code modules included in the ES6 revision of JavaScript, instead of previous idiosyncratic solutions such as CommonJS and AMD. ES modules let you freely and seamlessly combine the most useful individual functions from your favorite libraries. This will eventually be possible natively everywhere, but Rollup lets you do it today.

Итак, установим сам rollup

npm install -D rollup

И плагины, необходимые для сборки react приложения

npm install -D rollup-plugin-peer-deps-external \ 
rollup-plugin-postcss-modules \
rollup-plugin-typescript2 \
@rollup/plugin-babel \
@rollup/plugin-commonjs \ 
@rollup/plugin-node-resolve \ 
@rollup/plugin-url @svgr/rollup

В package.json добавляем секции, которые нам дадут экспортировать npm пакет

{
    "main": "dist/index.js",
    "module": "dist/index.es.js",
    "source": "src/index.tsx",
    "engines": {
        "node": ">=14"
    },
    "peerDependencies": {
        "react": ">=16.13.0",
        "react-dom": ">=16.13.0"
        ...
    },
    "dependencies": {
        ...
        "react": "^16.13.1",
        "react-dom": "^16.13.1",
        ...
    },
    "devDependencies": {
        "@rollup/plugin-babel": "^5.2.2",
        "@rollup/plugin-commonjs": "^16.0.0",
        "@rollup/plugin-node-resolve": "^10.0.0",
        "@rollup/plugin-url": "^5.0.1",
        "@svgr/rollup": "^5.5.0",
        "node-sass": "^4.13.1",
        "react-router-dom": "^5.1.2",
        "react-scripts": "^3.4.1",
        "rollup": "^2.41.2",
        "rollup-plugin-analyzer": "^4.0.0",
        "rollup-plugin-peer-deps-external": "^2.2.4",
        "rollup-plugin-postcss-modules": "^2.0.2",
        "rollup-plugin-typescript2": "^0.29.0",
        "typescript": "^3.8.3"
    },
    "files": [
        "dist"
    ],
    ...
}

Следующим шагом добавляем rollup.config.js

import typescript from "rollup-plugin-typescript2";
import commonjs from "@rollup/plugin-commonjs";
import external from "rollup-plugin-peer-deps-external";
import postcss from 'rollup-plugin-postcss-modules'
import resolve from "@rollup/plugin-node-resolve";
import analyze from 'rollup-plugin-analyzer';
import svgr from "@svgr/rollup";
import pkg from "./package.json";

export default {
    input: "src/index.tsx",
    output: [
        {
            file: pkg.main,
            format: "cjs",
            exports: "named",
            sourcemap: true,
        }
    ],
    plugins: [
        external(),
        postcss({
            extract: true,
            writeDefinitions: false,
        }),
        svgr(),
        resolve(),
        typescript({
            rollupCommonJSResolveHack: true,
            clean: true,
        }),
        commonjs({sourceMap: false}),
        analyze({
            summaryOnly: true
        }),
    ],
};

Добавляем секции запуска

"scripts": {
        "test": "react-scripts test",
        "build": "rollup -c",
        "start": "rollup -c -w --no-treeshake",
        "build-example": "REACT_APP_EXAMPLE=true react-scripts build",
        "start-example-local": "REACT_APP_EXAMPLE=true react-scripts start",
        "start-example-dev": "REACT_APP_EXAMPLE=true REACT_APP_STAGE=dev react-scripts start",
        "start-example-test": "REACT_APP_EXAMPLE=true REACT_APP_STAGE=test react-scripts start"
    },

Как видно, я использую отдельные команды для запуска example CRA приложения в различных средах с разными backend серверами.

Для сборки в режиме dev для ускорения сборки я не использую treeshaking, это сокращает время сборки примерно на 5 секунд.

Приведу также настройку своего typescript компилятора

{
    "compilerOptions": {
        "outDir": "build",
        "module": "esnext",
        "target": "es5",
        "lib": [
            "es6",
            "dom",
            "es2016",
            "es2017"
        ],
        "sourceMap": true,
        "allowJs": false,
        "jsx": "react",
        "declaration": true,
        "moduleResolution": "node",
        "forceConsistentCasingInFileNames": true,
        "noImplicitReturns": true,
        "noImplicitThis": true,
        "noImplicitAny": true,
        "strictNullChecks": true,
        "suppressImplicitAnyIndexErrors": true,
        "noUnusedLocals": true,
        "noUnusedParameters": true,
        "skipLibCheck": true,
        "esModuleInterop": true,
        "allowSyntheticDefaultImports": true,
        "strict": true,
        "resolveJsonModule": true,
        "isolatedModules": true,
        "noEmit": true,
        "noFallthroughCasesInSwitch": true,
        "experimentalDecorators": true,
        "useDefineForClassFields": true
    },
    "include": [
        "src"
    ],
    "exclude": [
        "node_modules",
        "build",
        "dist",
        "rollup.config.js"
    ]
}

Сборка

Запускаем команду

npm run build

> @online/online-game-frontend@1.0.0 build /Users/kroniak/Workspaces/jugru/online/game/game-demo-frontend
> rollup -c


src/index.tsx → dist/index.js...
-----------------------------
Rollup File Analysis
-----------------------------
bundle size:    5.066 MB
original size:  5.946 MB
code reduction: 14.79 %
module count:   592

created dist/index.js in 18.4s

Process finished with exit code 0

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

Все! Пакет готов к публикации как npm пакет в ваш корпоративный или публичный репозиторий.

Apple M1 vs Intel x86 первое впечатление

Nikolay Molchanov — Sun, 17 Jan 2021 14:43:41 GMT

Apple M1

Так как хайп вокруг этого процессора Apple M1 развивается уже второй месяц, я решил тоже сесть на этот силиконовый поезд.

Выдался прекрасный повод - требовалась замена домашнему macbook. И после недолгого ожидания был приобретена американская версия Apple Macbook Air 2020 Late на процессоре Apple M1.

На вид это обычный macbook air, изменений визуальных, которые бы отличали новую партию, нет никаких. Кроме отсутствующих вентиляторов и переделанной во всей линейке клавиатуры, конечно.

А по внутренней архитектуре нового процессора обещают много % роста производительности.

Сравнение

На состояние января 2021 большое кол-во обычных десктопных приложений уже кое как портировано на ARM, а вот с инструментами для разработчика все обстоит не так хорошо, как и с профессиональным софтом.

Визуально интерфейс работает быстро и отзывчиво, так же как и на pro.

Поэтому я решил прогнать синтетические тесты на air в сравнении с моим macbook pro 15 mid 2019 на i7 в коротком и длительном тесте.

Geekbench 5

Я в большом недоумении от такого результата сравнения оборудования за 110 тысяч (air) и за 250 (pro).

Производительность в single-core mode и multi-core mode, как в Compute Test отличается в 2 раза в пользу Apple M1.

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

Geekbench 5 CPU

Geekbench 5 Compute

Docker, DevTools

А вообщем и все из того что доступно в стабильной версии на данный момент.

Docker for Mac в сырой Preview, так же как и JB Idea и VS Code. NodeJs 14 еще не доступен, как и Dotnet 5 SDK.

Буду ждать Docker, JB Idea и Rider под M1 процессор для настоящего тестирования живьём.

Если Air будет быстрее, смысл в MacBook Pro на Intel для меня пропадает полностью.

Public Game Release Motivation

Nikolay Molchanov — Tue, 22 Dec 2020 21:53:00 GMT

TLDR; game.jugru.org.

Пост о публичной части игрового приложения.

Предыстория

Моя команда выпустила к Joker 2020 beta версию игрового вида конференции нового типа.

Основная идея: персонаж может бегать и взаимодействовать с другими игроками и партнерами через webRTC.

Игровая платформа до сих пор доступна на основном портале live.jugru.org.

Мотивация

После тестирования данной технологии на Joker 2020 и других конференциях сезона, я столкнулся с проблемой, что функционал, который будет дорабатываться до нового сезона конференции, просто негде посмотреть и тестировать. Необходимо было простое решение массового доступа до игровой части вне конференционного сезона.

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

Имя ему game.jugru.org.

Задачи

Публикацией сервиса я решил задачи:

Тестирования на большом кол-ве пользователей функциональности до запуска на основном продукте
Сбор фидбека с клиентов во время проведения звонком и митинг румов
Проведение митапов с интеграцией с youtube
Обкатку новых технических решений в части авторизации, SFU webRTC, net5
Подготовки к продуктизации решения

Запуск и изменения

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

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

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

Модификация backend заняла почти 2 недели и привела с попутными исправлениями TODO меток и технического долга к рефакторингу почти 30% кодовой базы.

Самые большие изменения были сделаны в авторизационной части и в части интеграционных тестов.

Модификация frontend части не понадобилась.

В итоге через 14 дней 17 декабря 2021 на площадке состоялся первый митап SpbDotNet с трансляцией в youtube.

Хорошо поехало!

Meet me in the game

Nikolay Molchanov — Tue, 15 Dec 2020 22:16:00 GMT

Yes! I have a Public Game Release v.0.1

Discover new meetings platform that brings back 2D games feelings and allows to schedule video calls

Now you can

Create personal space for meeting
Fun with your friends and colleagues

Feedbacks

I need your feedback and any ideas! You can send it at github.

What about money?

Currently we have a beta-version and don't have commercial plans. Feel free to use this platform for your meetings, meetups or conferences. If you've faced with any issues while using this platform or have a сommercial offer please reach out to us!

Photo by NeONBRAND / Unsplash

What about feature and plans?

I have a big backlog for this product.

In first things will be implemented:

OAuth with Google and Apple
Admin pages for room owners with controlling players
SFU webRTC component for massive communications

Photo by Christina @ wocintechchat.com / Unsplash