Как лучше структурировать модульные тесты Jasmine так, чтобы они не заканчивались огромным файлом?

Question

Я хочу убедиться, что мои модульные тесты доступны для чтения и сопровождения, а не помещать все тесты для моего компонента (или класса) в один файл, как это сейчас кажется "наилучшей практикой". Я думаю, что эта практика пагубна для всего, кроме тривиального кода или компонентов, и может стать негативной силой во всех кодовых базах JS / TS, которые я видел.

Не являясь разработчиком внешнего интерфейса, я изо всех сил пытаюсь найти или увидеть лучшую альтернативу, но пока единственная опция, которая решает проблему «толстого тестового файла», - это создание папки specs для каждого компонента / службы и:

• создать один тестовый файл для каждого метода

или

• создать один тестовый файл для описания "контекста"

Когда требуется общее состояние или настройка, я могу создать «вспомогательный» сервис или некоторые другие общие функции, которые можно вызывать из тестов, которые в этом нуждаются.

Считается ли это чем-то приемлемым или же этот вопрос еще не решен с точки зрения передовой практики?

Answer 1

Возьмите проблему по-другому: почему ваши тесты такие тяжелые?

Согласно руководству по стилю , вам следует рассмотреть возможность ограничения ваших файлов до 400строки кодов.

Удаление шаблона, импорта и пробелов, что соответствует примерно 300 строкам кода.Ваши возможности нг ограничены этим?

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

Кроме того, при условии, что вы следуете этим правилам и у вас все еще есть массивные тестовые файлы, есть несколько решений для уменьшения количества кода, необходимого для тестирования:

• Для макетов,вы можете создать отдельный файл в той же папке вашей функции ng
• Вы можете разделить свои тесты на несколько файлов, каждый из которых предназначен для определенной задачи (***.ui.spec.ts, ***.http.spec.ts ...)
• Вы также можете разложить свой тестовый код по классам / константам, чтобы сделать его многократно используемым

И, наконец,

, но пока единственный вариант, который исправляетПроблема "толстого тестового файла" заключается в создании папки specs для каждого компонента / службы

Неправильно.Согласно руководству по стилю ,

Для эффективной работы необходимо иметь возможность быстро находить файлы, особенно когда вы не знаете (или не помните) имена файлов.Хранение связанных файлов рядом друг с другом в интуитивно понятном месте экономит время.Описательная структура папок имеет огромное значение для вас и людей, которые приходят за вами

Si, вы должны держать тестовые файлы рядом с их функцией.