На мой взгляд, это паттерн. Тесты не должны быть простыми… Потому что пользователи ведут себя крайне непросто. Не существует действия «оплатить покупки в интернет-магазине» без действия «добавить товары в корзину»… Этот примитивный пример масштабируется на любую систему. И ограничивается лишь функциональными возможностями пользователя.
Это примерно то же самое, что говорить «тех-задание» — это паттерн. А user-story — антипаттерн. Сайты, программы, даже API постепенно переходят из набора функциональностей в набор сценариев для пользователя по реализации этих функциональностей. Уже почти нет форм с кучей кнопок на них… Есть call-to-action-ы, есть вероятности тех или иных сценариев… Это можно анализировать, изучать пользователей, выделять приоритетные сценарии, а не приоритетные функции, покрывать эти сценарии тестами. Теория тестирования, BDD идеи и т.д. подтягиваются к реальности, но, к сожалению, и в них пока есть то, что вызывает грусть.
— По-вашему проще поддерживать 2000 маленьких тестов, а не 100 сценарийных? :) Мой опыт говорит об обратном. Сценарии можно разбивать по тематикам, включать в разные сэты тестов — после падения видеть сразу, что вот в этой «сфере» у нас беда. Это очень удобно. С маленькими проверками такой прозрачности не добиться…
— По поводу предположений, в каком-методе. В стэк-трейсе всегда видна цепочка вызовов — видно в каком методе началось и где мы упали. Если всё правильно обработано, то ясное сообщение в Exception. Если и этого недостаточно, логи, если и этого — ну можно отдельно этот тест запустить и посмотреть глазами :) Ну или пройти по сценарию, если Software Developer in Test позаботился о том, чтобы тесты были читабельные и понятные. В конце концов Debug )))
-Тролли априори не троллят маленькими операциями :)
— Код-ревью — замечательная штука. Тут спорить не о чем
Да Тесты совершают намного больше одного действия. Они заточены под сценарии поведения пользователей системы — включают в себя ненормальное поведение пользователей и «троллей». Объём функциональности продукта, на самом деле, большой… Не гигантский, но большой.
Да. Ни слова… Потому что язык, как мне кажется, надо выбирать не под проект, а под спектр потенциальных задач. Потому что проект как начался, так и закончится, а специалист должен остаться специалистом, не заточенным под вот эту вот конкретную функциональность.
Хорошо, спасибо, могу называть это так — не принципиально. Принципиально в данном случае то, что в большинстве случаев, хотят именно такого специалиста, но не могут ни сформулировать это, ни найти его. В большинстве случаев, потому что таких специалистов крайне мало…
Ну когда нет реальных статей, сравнивающих два движка, а решение надо принимать быстро, то, уж извините…
Уже позже, пытаясь сравнить, — по ощущениям проход по свинговому дереву у Jemmy не оптимизирован и работает медленнее, чем у Fest (это мнение коллеги, который работает с Jemmy). Поэтому, как я понял, те, кто используют Jemmy, не всегда, но стараются при наличии множества проверок на одном слепке дерева работать с ним в памяти. С Fest таких проблем нет и можно для каждого компонента в отдельности запускать поиск, — никакой видимой потери в скорости не наблюдается.
Лишь иногда. У нас прекрасное/близкое к идеальному MVC, потому за всё время проекта не было ни одного прецедента наложения/«выезжания». Так что вставлять эти проверки — только усложнять и замедлять тесты. По идее компоненты, которые находятся за другими или вне видимой области не попадают в dirty region и, думаю, у AWT можно эту информацию получить. Но уверенности нет, надо попробовать.
Это примерно то же самое, что говорить «тех-задание» — это паттерн. А user-story — антипаттерн. Сайты, программы, даже API постепенно переходят из набора функциональностей в набор сценариев для пользователя по реализации этих функциональностей. Уже почти нет форм с кучей кнопок на них… Есть call-to-action-ы, есть вероятности тех или иных сценариев… Это можно анализировать, изучать пользователей, выделять приоритетные сценарии, а не приоритетные функции, покрывать эти сценарии тестами. Теория тестирования, BDD идеи и т.д. подтягиваются к реальности, но, к сожалению, и в них пока есть то, что вызывает грусть.
— По-вашему проще поддерживать 2000 маленьких тестов, а не 100 сценарийных? :) Мой опыт говорит об обратном. Сценарии можно разбивать по тематикам, включать в разные сэты тестов — после падения видеть сразу, что вот в этой «сфере» у нас беда. Это очень удобно. С маленькими проверками такой прозрачности не добиться…
— По поводу предположений, в каком-методе. В стэк-трейсе всегда видна цепочка вызовов — видно в каком методе началось и где мы упали. Если всё правильно обработано, то ясное сообщение в Exception. Если и этого недостаточно, логи, если и этого — ну можно отдельно этот тест запустить и посмотреть глазами :) Ну или пройти по сценарию, если Software Developer in Test позаботился о том, чтобы тесты были читабельные и понятные. В конце концов Debug )))
-Тролли априори не троллят маленькими операциями :)
— Код-ревью — замечательная штука. Тут спорить не о чем
Да. Ни слова… Потому что язык, как мне кажется, надо выбирать не под проект, а под спектр потенциальных задач. Потому что проект как начался, так и закончится, а специалист должен остаться специалистом, не заточенным под вот эту вот конкретную функциональность.
Над продуктовой разработкой в проекте :)
Уже позже, пытаясь сравнить, — по ощущениям проход по свинговому дереву у Jemmy не оптимизирован и работает медленнее, чем у Fest (это мнение коллеги, который работает с Jemmy). Поэтому, как я понял, те, кто используют Jemmy, не всегда, но стараются при наличии множества проверок на одном слепке дерева работать с ним в памяти. С Fest таких проблем нет и можно для каждого компонента в отдельности запускать поиск, — никакой видимой потери в скорости не наблюдается.
docs.oracle.com/javase/1.5.0/docs/api/javax/swing/RepaintManager.html
Возможно, это то, что нужно.