FuncTest. Автоматическое тестирование для 7.7.
Наши ожидания от функционала любой программы (в том числе и конфигурации 1С) можно записывать в виде, понятном для компьютера и затем использовать эти записи для автоматической проверки сохранения программой ожидаемого функционала.
Полезно для контроля над ошибками при внесении в программу изменений.
Так же может применяться, как способ написания ТЗ.
Полезно для контроля над ошибками при внесении в программу изменений.
Так же может применяться, как способ написания ТЗ.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Полностью прочитал домашнюю страничку. Впечатлило, буду внедрять к себе. Только походу прочтения появился вопрос, а если кинуть проверку заполнения табличной части документа с разнообразными перещетами, протестирует ли она это?
В любом случае. Выражаю свою глубокую благодарность за такую серьезную работу. Спасибо.
В любом случае. Выражаю свою глубокую благодарность за такую серьезную работу. Спасибо.
Спасибо за полезную программу :)
А очень геморно сделать, чтобы эталоны тестов хранились в базе, а классы и описания тестов отдельно в выбранном месте едином для всех баз. Смысл в том , что много почти однотипных баз и не хочется между ними копировать тесты :)
А очень геморно сделать, чтобы эталоны тестов хранились в базе, а классы и описания тестов отдельно в выбранном месте едином для всех баз. Смысл в том , что много почти однотипных баз и не хочется между ними копировать тесты :)
(3) Рад, что понравилось.
По вопросу. Мы сейчас говорим о функциональных тестах (TestBrowser) или о юниттестах?
Юниттесты - это по сути своей маленькие программки. Их можно хранить где угодно и подключать через //#include в defcls.prm
С функциональными тестами сложнее, поскольку там активно используется база данных. А все ссылки на объекты БД хранятся в виде ЗначениеВСтрокуВнутр(), так что "расшарить" ожидания - это большой гемор. Если как-то решить проблему универсального хранения ссылок на объекты БД, то гемор рассосется. Но как именно это сделать я пока не знаю.
По вопросу. Мы сейчас говорим о функциональных тестах (TestBrowser) или о юниттестах?
Юниттесты - это по сути своей маленькие программки. Их можно хранить где угодно и подключать через //#include в defcls.prm
С функциональными тестами сложнее, поскольку там активно используется база данных. А все ссылки на объекты БД хранятся в виде ЗначениеВСтрокуВнутр(), так что "расшарить" ожидания - это большой гемор. Если как-то решить проблему универсального хранения ссылок на объекты БД, то гемор рассосется. Но как именно это сделать я пока не знаю.
(8) Ну пожалуй да. Там единственная подстава в том, что ожидания хранятся вместе с условиями, а в условиях наверняка будут ссылки на объекты БД. Условия хранятся в первой строчке - ее в твоем случае надо проигнорировать. Если остальные строки совпадают, то должно быть все хорошо.
Ты пощупай и спрашивай уже более конкретно, помогу, чем смогу.
Ты пощупай и спрашивай уже более конкретно, помогу, чем смогу.
0.23.0
[+] Метод AssertFail теперь умеет работать и с функциями. Bug 4193
[+] Добавил в класс ТестовыйСлучай методы ПроверитьБольше() и ПроверитьБольшеИлиРавно()
[+] Добавил сортировку имен тестовых классов в окошке обработки запуска всех юниттестов.
[+] Обработка запуска юниттестов теперь запоминает расставленные галочки на тестовых классах между сеансами.
[+] При открытии обработки запуска юниттестов теперь автоматически выключается оптимизация. При закрытии обработки - восстанавливается предыдущее значение.
[+] Метод AssertFail теперь умеет работать и с функциями. Bug 4193
[+] Добавил в класс ТестовыйСлучай методы ПроверитьБольше() и ПроверитьБольшеИлиРавно()
[+] Добавил сортировку имен тестовых классов в окошке обработки запуска всех юниттестов.
[+] Обработка запуска юниттестов теперь запоминает расставленные галочки на тестовых классах между сеансами.
[+] При открытии обработки запуска юниттестов теперь автоматически выключается оптимизация. При закрытии обработки - восстанавливается предыдущее значение.
