Если я правильно понял статью — то это пример достаточно плохого js разработчика.
Мало того что она не разобралась почему stream вдруг считал файл в память(он не должен github.com/nodejs/help/issues/194) и просто использовала npm библиотеку, так еще и было предположение считать файл с данными в память целиком(ненуаче такого ?).
Хочу заметить что они настолько отвратительно себя показывают, что уже переползают на десктопы и мобилки, а вот наоборот ни у кого особенно не выходит :)
Есть несколько вопросов:
Над какими проектами с каким количеством людей вы работали?
Использовался ли в этих проектах предложенный вами подход(#i1 ul>li>div {}) ?
Встретились ли вам какие-нибудь минусы ?
>Цель — обеспечить качество кода, когда изменения делаются не в самом тестируемом классе, а в используемых им других классах.
1. У вас получается что качество кода «используемых им других классов.» обеспечивается тестами написанными у тех кто от этих классов зависит. Это достаточно странная логика.
2. На автономные классы без зависимостей по такой логике тесты можно не писать.
При нормальном подходе к тестам, зависимости в свою очередь должны быть покрыты тестами, так что дополнительные проверки им не нужны.
>В итоге вам не надо писать 8 тестов для непубличного метода и 8 тестов для публичного.
Если у вас полностью покрыт публичный метод, и у вас есть правило покрывать все публичные методы. Непонятно зачем вообще в таком случае проверять приватный.
При тестировании приватных методов, тестируются не контракты, а конкретная реализация.
При изменении внутренней структуры класса(например пару методов удалили, другую пару объединили) не будет никакой возможности узнать не нарушились ли внешние контракты, так как тесты все равно упадут, и все придется внимательно проверять руками.
А проблема с копипастом может решаться хэлпером для создания минимальной дефолтной конфигурации.
Мало того что она не разобралась почему stream вдруг считал файл в память(он не должен github.com/nodejs/help/issues/194) и просто использовала npm библиотеку, так еще и было предположение считать файл с данными в память целиком(ненуаче такого ?).
Это неправда :) на подавляющем большинстве веток машинисты в кабине есть :)
Есть несколько вопросов:
Над какими проектами с каким количеством людей вы работали?
Использовался ли в этих проектах предложенный вами подход(#i1 ul>li>div {}) ?
Встретились ли вам какие-нибудь минусы ?
Когда присылают фиче-реквест — открыть трекер, вместо ответа «да мы подумаем/попробуем, спасибо» начинается какая то непонятная полемика.
Впечатление так себе.
1. У вас получается что качество кода «используемых им других классов.» обеспечивается тестами написанными у тех кто от этих классов зависит. Это достаточно странная логика.
2. На автономные классы без зависимостей по такой логике тесты можно не писать.
При нормальном подходе к тестам, зависимости в свою очередь должны быть покрыты тестами, так что дополнительные проверки им не нужны.
Если у вас полностью покрыт публичный метод, и у вас есть правило покрывать все публичные методы. Непонятно зачем вообще в таком случае проверять приватный.
непонятна цель написания тестов в таком случае. При измении кода они не помогут вам найти ошибку.
>Хелперы — это палка с двумя концами. Один помогает, другой бьет по башке.
Проблема не в хелперах, а в — «Когда у вас есть лес классов из хелперов и непонятно, какой в вашем случае подходит, вы просто напишете новый.»
Возможно вам стоит начать с наведения порядка в проекте. Думаю что много аспектов станет проще, не только тестирование.
При тестировании приватных методов, тестируются не контракты, а конкретная реализация.
При изменении внутренней структуры класса(например пару методов удалили, другую пару объединили) не будет никакой возможности узнать не нарушились ли внешние контракты, так как тесты все равно упадут, и все придется внимательно проверять руками.
А проблема с копипастом может решаться хэлпером для создания минимальной дефолтной конфигурации.
Почему?