Comments 12
Похоже на ужасный машинный перевод.
Недавно заинтересовался возможностью авто-тестирования JS'а и хочу понять как оно таки работает. Ведь по факту тест это «зеркало» кода, т.е трудозатраты возрастают раза в полтора, и иногда это всёравно может не дать нужный эффект(функции можно протестировать, а вот увидит ли пользователь то что задумывалось — уже сложнее). Знаю что есть selenium который по факту просто кликер.
Если кому не сложно — посоветуйте литературу и/или обзор библиотек для авто-тестирование JS. Больше всего интересует возможность тестирования backbone.
Если кому не сложно — посоветуйте литературу и/или обзор библиотек для авто-тестирование JS. Больше всего интересует возможность тестирования backbone.
> Идеальный вариант — это тест в котором находится один вызов ф-ции expect
Чего ж один — давайте сразу ноль.
Насколько примитивными должны быть фловы в приложении чтоб их можно было протестировать одним ассертом?
Во сколько раз возрастет количество тестов если сложный флоу разбить на 10-15 одиночных тестов, и не является это само по себе усложнением, замаскированным под упрощение?
Чего ж один — давайте сразу ноль.
Насколько примитивными должны быть фловы в приложении чтоб их можно было протестировать одним ассертом?
Во сколько раз возрастет количество тестов если сложный флоу разбить на 10-15 одиночных тестов, и не является это само по себе усложнением, замаскированным под упрощение?
Да, именно. Ведь когда Вам дают, например, интернет-магазин на разработку, то Вы начинаете дробить все на модули, модели, контроллеры, вьюхи, фичи и прочее. Это ведь упрощает общее понимание картины, не так ли? Почему бы не делать то же самое в тестах?
Конечно, но я не считаю контроллер «плохим» если в нем больше скольки-то там методов, или вьюху «плохой» потому что на ней больше 1-го поля ввода, например.
А я считаю контроллер плохим, если в нем экшен больше 20-30 строк кода. Скажу даже больше, я считаю любой метод плохим, который называется плохо или если метод принимает больше 3 аргументов, или если у метода есть статические зависимости и таких «если» целая куча.
Все конечно же относительно, но есть так называемые «Best Practices», которые помогают делать код лучше. Следовать им или нет — это уже другой вопрос.
Все конечно же относительно, но есть так называемые «Best Practices», которые помогают делать код лучше. Следовать им или нет — это уже другой вопрос.
Сложный флоу в unit-тесте? А как Вы его описываете в it('...')?
По мне так критерий должен быть примерно таким — можешь кратко сформулировать в it, что этот тест проверяет — не принципиально, будет ли там 1 expect или 5. Не можешь — надо разбить.
А в целом, на мой взгляд, использование Arrange Act Assert (AAA) Pattern полезнее правила «1 expect».
По мне так критерий должен быть примерно таким — можешь кратко сформулировать в it, что этот тест проверяет — не принципиально, будет ли там 1 expect или 5. Не можешь — надо разбить.
А в целом, на мой взгляд, использование Arrange Act Assert (AAA) Pattern полезнее правила «1 expect».
AAA не противоречит «1 expect», поэтому просто не может быть лучше или хуже:
1. Arrange — для этого и существуют методы before/after/around each и их аналоги (setup, teardown, etc.).
2. Act — не принципиально где вызывать, в setUp-e или в самом тесте, зависит от ситуации.
3. Assert — ожидаемый результат, пишется только в it.
К-во expect-ов — это же часть SOLID. Один тест тестирует, что-то одно. При этом же документация, которая потом создается на базе тестов получается на порядок качественней и детальней.
1. Arrange — для этого и существуют методы before/after/around each и их аналоги (setup, teardown, etc.).
2. Act — не принципиально где вызывать, в setUp-e или в самом тесте, зависит от ситуации.
3. Assert — ожидаемый результат, пишется только в it.
К-во expect-ов — это же часть SOLID. Один тест тестирует, что-то одно. При этом же документация, которая потом создается на базе тестов получается на порядок качественней и детальней.
А где я сказал, что оно противоречит? Я сказал «полезнее».
> 1. Arrange — для этого и существуют методы before/after/around each и их аналоги (setup, teardown, etc.).
Вы на каждый тест еще свой describe и beforeEach предлагаете создавать? При чем тут after вообще не очень понял. По мне так в некоторых случаях читабельность ухудшится.
> 2. Act — не принципиально где вызывать, в setUp-e или в самом тесте, зависит от ситуации.
Да можно, конечно, кто мешает. Паттерн то существует для повышения структурированности и читабельности, а не для маниакального написания тестов именно так, как в одном примере показано.
> К-во expect-ов — это же часть SOLID. Один тест тестирует, что-то одно.
Одно с каким уровнем детализации?
В целом, как то складывается ощущение, что Вы хотите поделить мир на черное и белое. У Вас серьезно на каждый тест свой describe и beforeEach? И на тестовой базе хотя бы в 1000 тестов везде один expect? Было бы интересно на такое посмотреть вместе с покрытием, а вдруг действительно хорошо выглядит. Нету ничего в открытом доступе?
> 1. Arrange — для этого и существуют методы before/after/around each и их аналоги (setup, teardown, etc.).
Вы на каждый тест еще свой describe и beforeEach предлагаете создавать? При чем тут after вообще не очень понял. По мне так в некоторых случаях читабельность ухудшится.
> 2. Act — не принципиально где вызывать, в setUp-e или в самом тесте, зависит от ситуации.
Да можно, конечно, кто мешает. Паттерн то существует для повышения структурированности и читабельности, а не для маниакального написания тестов именно так, как в одном примере показано.
> К-во expect-ов — это же часть SOLID. Один тест тестирует, что-то одно.
Одно с каким уровнем детализации?
В целом, как то складывается ощущение, что Вы хотите поделить мир на черное и белое. У Вас серьезно на каждый тест свой describe и beforeEach? И на тестовой базе хотя бы в 1000 тестов везде один expect? Было бы интересно на такое посмотреть вместе с покрытием, а вдруг действительно хорошо выглядит. Нету ничего в открытом доступе?
А какие у Jasmine DRY плюсы и минусы по сравнению с аналогами?
Sign up to leave a comment.
Jasmine DRY: а ты правильно пишешь тесты?