Comments 19
Расплывчатые скриншоты кода выглядят очень нечитаемо.
Как такой скриншот можно добавлять в статью? :)
1)
2)
Плагин называется TestDok или TestDox? Спрашиваю, потому что TestDok я не нашел, а если я инсталлирую TestDox то IDEA даже не стартует, т.к. плагин выкидывает ошибку. IDEA 2016.3.5
Большую часть кода я не пишу, а генерю. Я никогда не пишу public class и еще что-то, конструктор, геттеры, сеттеры и т.п. Уже на протяжении лет 8-ми я никогда с нуля сам руками не создаю метод. Я просто пишу в тесте, как он должен выглядеть, и после этого IDE для меня все генерирует автоматически.
Подскажите, как это делается на практике? Например в IDEA (По гуглил — сходу не нашел)…
В отечественных учебных заведениях читают курс «Планирование эксперимента». Не успели ли тестеры программного обеспечения выработать чего-нибудь похожего?
«Одна школа утверждает важность того-то, другая того-то» — это как-то не надёжно, на уровне ведовства. Хотелось бы немного науки. Построения математической модели для тестирования, определения характеристик и расчёт оптимальной стратегии тестирования.
«Одна школа утверждает важность того-то, другая того-то» — это как-то не надёжно, на уровне ведовства. Хотелось бы немного науки. Построения математической модели для тестирования, определения характеристик и расчёт оптимальной стратегии тестирования.
К сожалению, эта отрасль развивается так быстро, что притяжение научных методов не везде уместно. Но много где есть вполне себе математические модели и алгоритмы, например в visual testing.
Научные методы всегда уместны. А все временно неопределённые факторы можно вводить как эмпирические коэффициенты, требующие дальнейшего уточнения.
Попробуйте, кто же мешает. Только может с программирования начать лучше? ;)
Программирование как раз неплохо покрыто математикой. Формализация понятия алгоритм, доказательство неалгоритмизуемости проблемы останова, множество формальных систем для автоматических доказательств теорем. Да и вручную доказана корректность немалого числа алгоритмов. Математика и программирование всегда идут бок о бок.
Что мешает применить математику к тестированию? Ведь желание явно есть — попытки считать покрытие кода тестами в процентах от количества строчек.
Что мешает применить математику к тестированию? Ведь желание явно есть — попытки считать покрытие кода тестами в процентах от количества строчек.
Погодите, то что вы перечислили — это малая часть программирования. А вот о прикладной разработке очень мало что «говорит наука». Есть узкие области в тестировании, которые тоже хорошо формализованы научно, например нагрузочное тестирование использует много из теории вероятности и статистики. Много разных алгоритмов для изображений используется как основа визуального тестирования и инструментов автоматизации как Sikuli. В дополнение к этому существует подход graph based testing, который основан на теории графов… :)
На мой взгляд мок-библиотеки надо использовать очень осторожно, потому что они могут прятать архитектурные проблемы приложения. Надо ли мокать сервис специальной библиотекой, если можно реализовать интерфейс этого сервиса в тесте и подсунуть эту реализацию тестируемому коду? Если мокать библиотекой сильно проще, чем реализовать соответствующий интерфейс, то вероятно есть проблемы с дизайном кода. Мок-библиотека позволяет о них не думать, а обойти их в тесте. Отказ от мок-библиотек стимулирует рефакторить код, делая его гибче.
Это просто расшифровка или дополненная версия?
Sign up to leave a comment.
Сага о том, как Java-разработчики должны тестировать свои приложения. Часть 1