Z
самое хорошее это юнит тесты конкретных методов
Size: a a a
2018 November 28
VP
Ну вот когда ты что-то делаешь, ты же делаешь это не просто так? Сначала пишешь сценарий. Из хорошо сформированной задачи сразу понятно что должно быть и как это проверить.
У нас не всегда это так, это прям отдельная борьба
Отчасти тесты призваны решить как раз проблему того, что никто точно не знает какая функциональность была кем добавлена =(
Отчасти тесты призваны решить как раз проблему того, что никто точно не знает какая функциональность была кем добавлена =(
Z
но просто так писать юнит тесты не получится, код должен быть тестопригодным с хорошей абстракцией
Z
У нас не всегда это так, это прям отдельная борьба
Отчасти тесты призваны решить как раз проблему того, что никто точно не знает какая функциональность была кем добавлена =(
Отчасти тесты призваны решить как раз проблему того, что никто точно не знает какая функциональность была кем добавлена =(
это организационные проблемы, они не решатся тестами
Z
Вот смотри. Я недавно делал как пример хорошего расширения. Примерно так когда ты описываешь функциональность тестировать становится просто и понятно. И ожидаемо что должно происходить https://github.com/axioma-project/MonthEndClosingMonitor
VP
это организационные проблемы, они не решатся тестами
Ну как минимум не поломаем существующее =)
Твоя правда, но к сожалению это уже не моя зона влияния, а убедительности мне пока не хватило =)
Твоя правда, но к сожалению это уже не моя зона влияния, а убедительности мне пока не хватило =)
VP
Большое спасибо за пример!
Z
А вот пример смоук теста веб клиента на селениуме https://github.com/zeegin/selenium_chrome_smoke
опять же сначала поведение, потом реализация
опять же сначала поведение, потом реализация
Z
Закрыть текущий легаси не получится тестами без разбора того как это должно работать.
Z
Вот хорошая статья о принципах тестирования https://m.habr.com/post/169381/
Z
Z
вот это важно
Z
нет смысла покрывать простой код тестами, нет смысла покрывать тестами то что будет активно рнфакторится
Z
сложный код без зависимостей это чистый юнит тест
Z
простой код с зависимостями - тут все сложно, моки хорошие в 1с мы не сделаем, потому надо либо интеграционный тест делать либо изначально отцепляемый код писать чтобы можно было фиктивные объекты подставить.
Z
а если нужно интеграционный - это чаще всего внешняя обработка с началом транзакции, подготовкой данных для теста, тестом и откатом транзакции:) вот такой финт ушами чтобы эталоны не готовить.
VP
Но все равно подготовка большого кол-ва данных занимает прилично времени. Например, простенький, отчет по продажам тянет с собой кучу зависимостей номенклатуры, группы, конрагенты и т.д.
В результате мы должны решить на сколько критичен для нас функицонал и готовы ли мы тратить время на покрытия его тестами, по крайней мере на начальном этапе, когда объем работы по написанию тестов огромный?
В результате мы должны решить на сколько критичен для нас функицонал и готовы ли мы тратить время на покрытия его тестами, по крайней мере на начальном этапе, когда объем работы по написанию тестов огромный?
Z
не нужно много данных для тестов. нужны контрольные данные для сценариев
Z
сначала пишешь какие сценарии могут быть, потом оотовишь данные для этих сценариеы, потом делаешь для них тесты
Z
вот это может быть не самое очевидное, например было меня спрашивали, как же мы тестировать будем нашу базу? у нас она 150 гб. вы что базу тестируете? нагрузочный тест? вы тестируете функционал. достаточно взять пустую базу.