Здравствуйте, Буравчик, Вы писали:

Б>Встретил интересную статью про тестирование. Статья хорошо структурирована, достаточно понятно доносит заложенные идеи и имеет примеры кода.
Я не понял в чём новшество и чем это отличается от моков. Это какая-то специфическая проблема экосистемы JavaScript что-ли?

The tests use a Nullable CommandLine to throw away stdout and Configurable Responses to provide pre-configured command-line arguments. They also use Output Tracking to see what would have been written to stdout.

Это полный аналог чего какой-нибудь Mockito.mock(CommandLine.class) и сделает в Java. Но не требуется ничего сувать в прод-код, все эти configurable resonses ( аналогом будет when().thenReturn() ) и tracking делается в тестовом коде (verify/ArgumentCaptor). Преимущество хотя бы в том, что в прод-артефакты никакая тестовая петрушка не попадает, но при этом можно мокать даже чужие библиотеки.
Серьёзный недостаток — вот забыли они в своём CommandLine.createNull что write() предусмотреть, что оказывается умеет кидать исключение, и всё, невозможно протестировать такой сценарий без того чтобы патчить прод-код.

Overlapping Sociable Tests... For example, imagine the dependency chain LoginController → Auth0Client → HttpClient:

— это то что я пытаюсь объяснить. Вот тут они оборвали цепочку на HttpClient не просто так, а потому что HttpClient лазит в сеть и требует ресурсы (Zero-Impact Instantiation... Don’t connect to external systems, start services, or perform long calculations.). Так что HttpClient придётся мокать (аналог моих тестов с моками репозитория), а потом отдельно тестировать The HttpClient tests check that HttpClient is correct, including using Narrow Integration Tests to check how it communicates with HTTP servers. (аналог моих репо+бд тестов или conformance).

Parameterless Instantiation... Ensure all classes have a constructor or factory that doesn’t take any parameters — серьёзно? Зачем responsibility смешивать? Классам классово, а инициализация отедяется в composition root. This test-specific factory method is easiest to maintain if it’s located in the production code next to the real constructors. Мде.. SRP, не слышали?.. Видимо в javascript не хватает вменяемой IDE и статической типизации.

... дальше потом почитаю, большая статья.

Здравствуйте, Буравчик, Вы писали:

Б>Встретил интересную статью про тестирование. Статья хорошо структурирована, достаточно понятно доносит заложенные идеи и имеет примеры кода.
Я не понял в чём новшество и чем это отличается от моков. Это какая-то специфическая проблема экосистемы JavaScript что-ли?

The tests use a Nullable CommandLine to throw away stdout and Configurable Responses to provide pre-configured command-line arguments. They also use Output Tracking to see what would have been written to stdout.

Это полный аналог чего какой-нибудь Mockito.mock(CommandLine.class) и сделает в Java. Но не требуется ничего сувать в прод-код, все эти configurable resonses ( аналогом будет when().thenReturn() ) и tracking делается в тестовом коде (verify/ArgumentCaptor). Преимущество хотя бы в том, что в прод-артефакты никакая тестовая петрушка не попадает, но при этом можно мокать даже чужие библиотеки.
Серьёзный недостаток — вот забыли они в своём CommandLine.createNull предусмотреть, что write() оказывается умеет кидать исключение, и всё, невозможно протестировать такой сценарий без того чтобы патчить прод-код.

Overlapping Sociable Tests... For example, imagine the dependency chain LoginController → Auth0Client → HttpClient:

— это то что я пытаюсь объяснить. Вот тут они оборвали цепочку на HttpClient не просто так, а потому что HttpClient лазит в сеть и требует ресурсы (Zero-Impact Instantiation... Don’t connect to external systems, start services, or perform long calculations.). Так что HttpClient придётся мокать (аналог моих тестов с моками репозитория), а потом отдельно тестировать The HttpClient tests check that HttpClient is correct, including using Narrow Integration Tests to check how it communicates with HTTP servers. (аналог моих репо+бд тестов или conformance).

Parameterless Instantiation... Ensure all classes have a constructor or factory that doesn’t take any parameters — серьёзно? Зачем responsibility смешивать? Классам классово, а инициализация отедяется в composition root. This test-specific factory method is easiest to maintain if it’s located in the production code next to the real constructors. Мде.. SRP, не слышали?.. Видимо в javascript не хватает вменяемой IDE и статической типизации.

... дальше потом почитаю, большая статья.