Я стараюсь использовать VerifyNoOtherCalls только когда используются какие-то внешние зависимости, которые чаще всего приводят к проблемам — базы данных здесь в приоритете, так что репозитории, по-моему, лучше как-то контроллировать.
Если возникнет необходимость дважды вызывать репозиторий, то тогда конечно придется этот тест переписывать, но по-моему лучше держать архитектуру такой, чтобы этого не случалось, если есть возможность.
По поводу структуры — предпочитаю не повторять структуру неймспейсов из тестируемого проекта, вместо этого просто держу все в папках с названиями классов, а внутри делю по тестовым классам по методам или даже подметодам. В случае с примером выше, можно даже целый тестовый класс назвать AuthenticationService.AuthenticateWithCorrectTokenShould. Критерия по разделению строго нет, просто слежу за тем, чтобы тестовые классы не становились слишком жирными. Для этого еще отдельно обращаю внимание на неиспользуемые зависимости, стараюсь, чтобы их было поменьше. Это, как мне кажется, помогает придерживаться SRP, а в итоге вместо обычных для индустрии медиаторов типа CommentaryService, где сложена вся логика работы с комментариями, у меня есть CreateCommentaryService, DeleteCommentaryService, LikeCommentaryService и ReplyCommentaryService. Все классы строго отвечают за бизнес-процессы, очень легко покрываются тестами, которые даже не всегда надо разносить по разным файлам (как можно понять по названиям, в них редко бывает больше одного метода).
Пока вроде бы устраивает, что получается. В основном даже не в самих тестах, а в том, как меняется код, чтобы повысить свою тестабильность.
Мне вот, кстати, поэтому нравится семантика Should. Когда тестовый класс заканчивается на слово Should и содержит тесты иногда только на один метод класса. Если у меня в классе типа AuthenticationService имеется два нетривиальных метода Authenticate и Logout, например, то мне будет не очень удобно наблюдать огромный тестовый класс, где черт ногу сломит. Вместо этого можно сделать тестовые классы AuthenticationService.AuthenticateShould и LogoutShould и в каждой фикстуре держать по пяток проверок, которые реально нужно осуществлять. Может получиться что-то типа.
public class AuthenticateShould
{
[Fact]
public async Task ReturnSuccess_WhenTokenCorrect()
{
var actual = await Authenticate("correct_token");
actual.Result.Should().Be(AuthenticationResult.Success);
}
[Fact]
public async Task ProlongateSessionForHour_WhenTokenCorrect()
{
currentMomentSetup.Returns(new DateTime(2019, 01, 01, 10, 05, 20));
await Authenticate("correct_token");
sessionRepository.Verify(r => r.RefreshSession(It.Is(userId), It.Is(sessionId), It.Is(new DateTime(2019, 01, 01, 11, 05, 20)), Times.Once);
sessionRepository.VerifyNoOtherCalls();
}
[Fact]
public async Task UpdateUserActivity_WhenTokenCorrect()
{
currentMomentSetup.Returns(new DateTime(2019, 02, 03));
await Authenticate("correct_token");
userRepository.Verify(r => r.Update(It.IsUpdateBuilder<User>().WithField(u => u.LastActivityDate, new DateTime(2019, 02, 03))), Times.Once);
userRepository.VerifyNoOtherCalls();
}
}
Успех выполнения операции состоит из кучи маленьких успехов. Это и запись в базу, и корректный возвращенный результат, и публикация сообщения в MQ. Это технически можно записать в один тест, но принцип «один тест — одна проверка» существует не просто так. Удобно, когда по одному взгляду на результат прогона (не на детали упавших тестов, а именно на результат прогона) видно, что именно идет не так. Например, кто-то нарушил формат сообщения в MQ, в прогоне может быть удобнее увидеть не просто: AcceptOrder_Successful failed, а скорее AcceptOrder_EventPublished failed. Все остальные два-три-десять тестов, которые тоже проверяют успех при этом вполне могут быть зелеными. Я сразу по прогону вижу, какая часть моего, возможно, здоровенного метода сломалась.
У меня помнится ещё с первой статьи подгорело знатно, но вторая держит планку. Хорошо, когда у компании такое прекрасное «сопроводительное письмо», можно не тратить на неё время.
Во всем этом семантичном и текстовом коде есть главная проблема. Программисты все сплошь в лучшем случае б2 (конечно, за исключениями), и поскольку кроме как на галеры английский язык на собесах не спрашивают (да и там не парятся), получаются вот эти перлы типа separated with вместо by.
Вот мы например по этой причине отказались от английского геркина в bdd и перешли на русский.
Не памяти, а данных. Когда сторонний клиент (например, расширение браузера) может получить доступ к тому, что ваш API передал через свой контракт ответа.
Оборачивать результат списка ресурсов (GET /entities) необходимо для закрытия уязвимости JS Array, которая может привести к утечке данных.
Побочным бонусом от этого оборачивания становится возможность докинуть информацию о пагинации не в заголовки.
Когда-то в детстве, когда телевизора не было, я слушал трансляции футбола по радио. И это было невероятно «зрелищно» (в фонетическом смысле), и нервы натягивались едва ли не сильнее чем сейчас. Как правильно сказал, JediPhilosopher, иногда достаточно талантливого комментатора, чтобы сделать процесс интересным.
алгоритмы не показатель ума, а лишь показатель того что человек знает алгоритмы
Мне кажется, это достаточно странная риторика. Вам часто доводится встречать глупых людей, которые знают алгоритмы? Или под «показателем ума» вы имеете в виду нечто специфичное, что не связано с алгоритмами?
Также интересно, откуда вы знаете, какие алгоритмы автор знал, а какие не знал? Что вообще значит «знать алгоритмы»? Вот например меня сейчас запри в комнате и заставь написать волновой алгоритм, я вряд ли это сделаю без ошибок. Но про его сложность ответить смогу, когда применить — тоже в курсе. Я знаю волновой алгоритм или нет?
Умение нагуглить алгоритмы и структуры данных, когда у тебя уже имеются их названия — это, в принципе, не самый крутой скилл. Опытный программист, конечно, сможет вбить правильный запрос, чтобы наткнуться на вышеперечисленное, но у джуна/стажера как правило бывают еще проблемы с формулировкой своей задачи для поисковика, и в такой ситуации гораздо выгоднее, если у него есть знания о том, что скорее подойдет. Притом знание реализации, возможно, не нужно, но про это и не сказали же. А с учетом того, сколько Яндекс и Контур тратят усилий на обучение студентов в Екб, с них и спрос другой, пусть вообще квантовые алгоритмы из головы достают!
Позволю себе влезть в затевающуюся дискуссию со своими пятью копейками из смежного мира дотнета. В разных местах по-разному используют статические классы, на моей работе это как правило приводит к:
1. Эпичный класс SomethingHelper, который наверное еще и partial, в котором смешалась в кучу вся хоть отчасти касающаяся некой сущности логика. Это спагетти, в котором невозможно найти нужный метод.
2. Поскольку это статический класс, то он не умеет управлять циклом жизни своих зависимостей, например, если кто-то триста лет назад использовал валидацию через БД, то теперь некий метод принимает там стратегию работы с БД, и это уже не просто Helper/Utils, а полноценная помесь Singleton и Strategy. Ухх.
3. Написание юнит-тестов на классы, которые пользуются этими Utils превращается в извращение, потому что какой-нибудь из методов ConvertNameToPhone наверняка валидирует то, что в имени есть три слова, каждое с большой буквы, и ваши юнит-тесты, которые должны проверять, что медиатор прочитал данные, и если ничего не нашел, то отправил сообщение в MQ, начинают пестреть «Ивановым Николаем Петровичем» и десятком других полей, которые для теста не имеют никакого значения, но ужасно необходимы Utils-методу.
К сожалению, уже подгорает и продолжить список не могу, но уверен, что в других компаниях свои антипаттерны хелперов.
> Простите, откуда вы это взяли? Как kh передаётся наша «х».
Вы правы, а я ошибся. В этих вопросах я дилетант, и свой С1 насамоучил. Осмелился высказать мнение, поскольку благодаря музыкальному бэкграунду всегда получаю комплименты в адрес произношения =)
Да, я не говорил, что это специфично для k и g, меня попросили про них подробнее же каментом выше.
> У них тоже есть говоры с чётким раздельным [ng] вместо [ŋ], и есть звуковые контексты, в которых оно превращается в два звука — я даже однажды слышал singing как [sıngıŋ] (или [sıngın], я их плохо различаю) в каком-то выступлении нейтива.
Ну во-первых, русская «к» не зря в транслите выглядит как «kh», нейтивы обычно произносят ее более мягко, через переднюю часть нёба, тогда как наш человек использует заднюю часть, выдавая твердую, ядрёную, отечественную КХ. В словах типа «cancel», где скорее «кьансел» получится, многие говорят «кхэнсел».
С «г» еще жосче, в «инговых окончаниях» она вообще горлом произносится будто бы, но у соотечественника это полноценная «г» через нёбо, как и «к». И часть слова, которая не должна акцентировать на себе фонетического внимания, становится центром композиции.
Многие годы игры в разных музыкальных коллективах, пишущих английские тексты и играющих каверы научили меня, что с дифтонгами, хитрыми 'р' и десятом 'э' люди справляются запросто при должной практике (особенно вокалист), а настоящее зло таится в безобидных на первый взгляд 't', 'k' и 'g'. Вот так ненейтивы и прокалываются.
Коллаборация и валерьянка. Я сам в такой ситуации оказался, когда сразу два сеньора-помидора из Канады выносили мозг месяцами, не в силах написать ничего сложнее хелловорлда. Не уверен что именно мне удалось донести до начальства необходимость их ухода с проекта, но сразу после этого я ушёл сам, ибо начальство, которое настолько в отрыве от происходящего вряд ли изменится.
1. Существуют работы, на которые не берут без высшего образования. Следует ли из этого, что высшее образование необходимо для выполнения обязанностей? Нет, это может означать что угодно: от «тут так принято» до «у нас дичайшая нагрузка рекрутеров, по 300 человек нанимаем в год, их надо отсеивать, хотя бы фильтром по наличию вышки».
2. Самостоятельно такую математику не выучить? Тогда зачем вы сидите за книжками? Впрочем, если речь идет о диссипативных системах в частности или дифурах в целом, то это хотя и нетривиально, но не что-то, требующее гения.
3. Как знания тервера и статистики связаны с гением? Даже если не считать, что эти ветви математики считаются самыми простыми и скучными по сравнению с теми же высшей алгеброй или топологией, да хоть бы и с теорией чисел.
4. И разумеется, есть только два варианта — заниматься-моей-работой или формочки верстать. Ничего между этим не существует. И первый вариант — это обязательно элитарная группа, куда не попасть без MBA/CSBS/подставь нужное.
Если возникнет необходимость дважды вызывать репозиторий, то тогда конечно придется этот тест переписывать, но по-моему лучше держать архитектуру такой, чтобы этого не случалось, если есть возможность.
По поводу структуры — предпочитаю не повторять структуру неймспейсов из тестируемого проекта, вместо этого просто держу все в папках с названиями классов, а внутри делю по тестовым классам по методам или даже подметодам. В случае с примером выше, можно даже целый тестовый класс назвать AuthenticationService.AuthenticateWithCorrectTokenShould. Критерия по разделению строго нет, просто слежу за тем, чтобы тестовые классы не становились слишком жирными. Для этого еще отдельно обращаю внимание на неиспользуемые зависимости, стараюсь, чтобы их было поменьше. Это, как мне кажется, помогает придерживаться SRP, а в итоге вместо обычных для индустрии медиаторов типа CommentaryService, где сложена вся логика работы с комментариями, у меня есть CreateCommentaryService, DeleteCommentaryService, LikeCommentaryService и ReplyCommentaryService. Все классы строго отвечают за бизнес-процессы, очень легко покрываются тестами, которые даже не всегда надо разносить по разным файлам (как можно понять по названиям, в них редко бывает больше одного метода).
Пока вроде бы устраивает, что получается. В основном даже не в самих тестах, а в том, как меняется код, чтобы повысить свою тестабильность.
Вот мы например по этой причине отказались от английского геркина в bdd и перешли на русский.
Побочным бонусом от этого оборачивания становится возможность докинуть информацию о пагинации не в заголовки.
Мне кажется, это достаточно странная риторика. Вам часто доводится встречать глупых людей, которые знают алгоритмы? Или под «показателем ума» вы имеете в виду нечто специфичное, что не связано с алгоритмами?
Также интересно, откуда вы знаете, какие алгоритмы автор знал, а какие не знал? Что вообще значит «знать алгоритмы»? Вот например меня сейчас запри в комнате и заставь написать волновой алгоритм, я вряд ли это сделаю без ошибок. Но про его сложность ответить смогу, когда применить — тоже в курсе. Я знаю волновой алгоритм или нет?
1. Эпичный класс SomethingHelper, который наверное еще и partial, в котором смешалась в кучу вся хоть отчасти касающаяся некой сущности логика. Это спагетти, в котором невозможно найти нужный метод.
2. Поскольку это статический класс, то он не умеет управлять циклом жизни своих зависимостей, например, если кто-то триста лет назад использовал валидацию через БД, то теперь некий метод принимает там стратегию работы с БД, и это уже не просто Helper/Utils, а полноценная помесь Singleton и Strategy. Ухх.
3. Написание юнит-тестов на классы, которые пользуются этими Utils превращается в извращение, потому что какой-нибудь из методов ConvertNameToPhone наверняка валидирует то, что в имени есть три слова, каждое с большой буквы, и ваши юнит-тесты, которые должны проверять, что медиатор прочитал данные, и если ничего не нашел, то отправил сообщение в MQ, начинают пестреть «Ивановым Николаем Петровичем» и десятком других полей, которые для теста не имеют никакого значения, но ужасно необходимы Utils-методу.
К сожалению, уже подгорает и продолжить список не могу, но уверен, что в других компаниях свои антипаттерны хелперов.
Вы правы, а я ошибся. В этих вопросах я дилетант, и свой С1 насамоучил. Осмелился высказать мнение, поскольку благодаря музыкальному бэкграунду всегда получаю комплименты в адрес произношения =)
Да, я не говорил, что это специфично для k и g, меня попросили про них подробнее же каментом выше.
> У них тоже есть говоры с чётким раздельным [ng] вместо [ŋ], и есть звуковые контексты, в которых оно превращается в два звука — я даже однажды слышал singing как [sıngıŋ] (или [sıngın], я их плохо различаю) в каком-то выступлении нейтива.
Но нигде не [singing], тем не менее.
С «г» еще жосче, в «инговых окончаниях» она вообще горлом произносится будто бы, но у соотечественника это полноценная «г» через нёбо, как и «к». И часть слова, которая не должна акцентировать на себе фонетического внимания, становится центром композиции.
Многие годы игры в разных музыкальных коллективах, пишущих английские тексты и играющих каверы научили меня, что с дифтонгами, хитрыми 'р' и десятом 'э' люди справляются запросто при должной практике (особенно вокалист), а настоящее зло таится в безобидных на первый взгляд 't', 'k' и 'g'. Вот так ненейтивы и прокалываются.
Коллаборация и валерьянка. Я сам в такой ситуации оказался, когда сразу два сеньора-помидора из Канады выносили мозг месяцами, не в силах написать ничего сложнее хелловорлда. Не уверен что именно мне удалось донести до начальства необходимость их ухода с проекта, но сразу после этого я ушёл сам, ибо начальство, которое настолько в отрыве от происходящего вряд ли изменится.
2. Самостоятельно такую математику не выучить? Тогда зачем вы сидите за книжками? Впрочем, если речь идет о диссипативных системах в частности или дифурах в целом, то это хотя и нетривиально, но не что-то, требующее гения.
3. Как знания тервера и статистики связаны с гением? Даже если не считать, что эти ветви математики считаются самыми простыми и скучными по сравнению с теми же высшей алгеброй или топологией, да хоть бы и с теорией чисел.
4. И разумеется, есть только два варианта — заниматься-моей-работой или формочки верстать. Ничего между этим не существует. И первый вариант — это обязательно элитарная группа, куда не попасть без MBA/CSBS/подставь нужное.