Comments 9
По умолчанию Karma-webpack собирает независимый бандл для каждого теста. Поэтому проблема очищения моков после каждого теста не стоит.
Сейчас собрал примитивный пример с inject-loader
, работает как надо.
Ведь это разные слои, webpack для внешних зависимостей, DI для зависимостей приложения.
Зачем смешивать? [ прошу прощения, ни туда написал ]
На эту тему автор уже отвечал в комментариях к прошлой статье: https://habrahabr.ru/post/329740/#comment_10258456
если у вам повезло, и у вас есть нормальный DI, то у вас все хорошо. А если не повезло — то proxyquire и компания — неплохой способ выкрутиться без переписывания кода целиком.
Давайте придумаем немного синтетический пример:
import function1 from 'module1';
export default () => function1()+1;
После чего мы просто мокаем module1 и expect(function1).to.be.called();
Проходит время, и Вася добавляет еще одну строчку:
import function1 from 'module1';
import function2 from 'module2';
export default () => function1()+function2()+1;
Но он не меняет тесты, а тесты как работали, так и работают.
Бывает и обратная ситуация — вы убираете строчку, а тесты как работали, так и работают.
Беда в том, что тесты должны не только «тестировать» поведение функции, те проверять результат — они должны служить вторым контуром проверки, обеспечивать еще один «момент подумать».
И, по хорошему, должны падать при _любом_ изменении логики програмы. Просто потому что они должны его детектить и подносить вам на блюдечке.
Да — совсем не круто править 10 тестов после того как изменил одну запятую. Но еще более не круто – не догадываться, что вы изменили чуть больше логики, чем думаете, этой одной запятой.
В свое время я пытался пропихнуть API для этого в proxyquire, но не срослось.
В rewiremock для мока можно определить то как он может быть вызван — toBeUsed, directChildOnly, calledFromMock, плюс режим isolation который будет ругаться на каждый неожиданный import.
Раз уж units tests are production code — относитесь к ним соотвествующе. Хотя конечно можно добавить тесты для тестов, но нельзя добавить тесты для моков, те заставить моки соотвествовать интерфейсам того, кого они собой замещают – тут нужен DI. Но он тоже не сахар.
DI хорош, когда в одну и туже розетку можно засунуть разные вилки. Если пара вилка/розетка всегда одна, и DI — исключительно для тестов — может его и не надо?
И, самое главное, многие вещи просто принято использовать «как есть». Именно поэтому 90% примеров моканья чего либо, мокают: fs, сеть, session storage, селекторы в редаксе и другой environment.
У вас метод индукции сбоит. В данный момент безаппеляционные утверждения исходят только с вашей стороны.
Вроде как приверженность только одного взгляда — и есть проявление радикального.
У меня каждый день есть возможности видеть плюсы и минусы разных подходов на разных языках… и в большинстве случаев использование «классического» DI — это или Java, или объектно ориентированный говнокод 5-то летней давности.
Webpack и моканье зависимостей