kb
08.05.2012 09:27
Всякие там паттерн-матчинги — хорошая идея для юнит-тестов, а то иначе приходится пользоваться костылями типа mock.ANY. Хотя и костыли вроде нормальные, просто если это делать средствами языка — будешь чувствовать себя мужиком с огромными яйцами.
8 comments
recommend
bookmark
subscribe
Зависит от языка же, не?
Что зависит? Ну я к тому, что в тестах часто надо из гигантской колбасы только кусочек заассертить. Удобно с матчингом это делать.
да причом тут яйца. Тут надёжность важна. (я кэп!111)
С другой стороны, неполный паттерн-матчинг — дырка, откуда при развитии софта полезут баги.
нет не дырка. во-первых, иногда хочется отдельно проверить. во-вторых, докажи, что неполный матчинг не может покрыться в другом месте.
просто у меня в тест проверяет, что в зависимости от одной хуйни, в конце в функции будет подставляться правильно первый параметр. если я от малоопытности еще второй параметр как-то да воспроизвёл (замокал и т.п.), увеличив код теста в 2 раза, то на третем параметре я понял, что лучше поставить mock.ANY и спать спокойно, т.к. тест лучше пусть тестирует что-то одно, иначе он моментально стаёт write-only.
при расширении индуктивного типа данных при полном матчинге предупреждения компилятора покажут, где нужно добавить матчинг нового варианта. Если на предупреждения класть (их выключением или игнорированием), то компилятор не поможет.
А, во-вторых, да, где надо, там доказываю (либо через подтипизацию, либо формальными средствами), что матчится всё, полностью и кошерно.
а, ну тут согласен полностью.
Ну, в данном случае, видимо, да, я имел в виду скорее матчинг в смысле "удобное языковое средство отсеять от структуры данных неинтересные нам данные". А индуктивные типы — очень мощная штука, хотелось бы воспользоваться когда-нибудь подобным.