Comments 4
Чтобы не поднимать все GWT окружение для тестов, придумали вот это code.google.com/p/gwt-test-utils/
Вполне неплохо работает.
Вполне неплохо работает.
Интересная вещь. Я её встречал, когда искал информацию по тестированию в GWT. Но меня смутило несколько моментов:
1) Давно не поддерживается — последний релиз в сентября 2013 года для версии GWT 2.5.0.
2) Используется reflection для получения элементов, что не отлавливается при компиляции.
3) Далеко не все UI элементы можно корректно создать в JVM (например, все элемент SmartGWT). Так что лучше полностью отказаться от работы с UI и разделять логику и UI (не зря же придумали паттерны MV* ?!) и тестировать всё кроме UI.
4) Там нет тестирования GWT RPC (только с mock'ами). Хотя теоретически можно прикрутить SyncProxy.
А Вы использовали эту либу в реальных проектах? На какой версии GWT работаете? Вообще спасибо за инфу, ещё посмотрю поподробнее.
1) Давно не поддерживается — последний релиз в сентября 2013 года для версии GWT 2.5.0.
2) Используется reflection для получения элементов, что не отлавливается при компиляции.
3) Далеко не все UI элементы можно корректно создать в JVM (например, все элемент SmartGWT). Так что лучше полностью отказаться от работы с UI и разделять логику и UI (не зря же придумали паттерны MV* ?!) и тестировать всё кроме UI.
4) Там нет тестирования GWT RPC (только с mock'ами). Хотя теоретически можно прикрутить SyncProxy.
А Вы использовали эту либу в реальных проектах? На какой версии GWT работаете? Вообще спасибо за инфу, ещё посмотрю поподробнее.
Вы, видимо, на гитхаб не заглянули, там вполне себе есть для 2.6 github.com/gwt-test-utils/gwt-test-utils/wiki/GWT-compatibility
Да, не все можно сымитировать, согласен, но с другой стороны такое и с классическими GWT тестами скорее всего не протестишь. Никто не спорит с тем, что нужно придерживаться разделения, но не всегда получается.
Например я активно использую SelectionModel из GWT поставки, но при этом её нельзя использовать в junit тестах, ибо внутренняя реализация использует Scheduler.get, который нельзя замокать никакими стандартными средствами. Здесь эта библиотечка подходит идеально.
Я всегда считал, что моков RPC сервисов вполне достаточно, а все остальное тестируется server side unit тестами (если конечно не пихать всю реализацию прямо в RPC сервлеты GWT)
Мы используем эту штуку как часть всей системы тестирования. То есть у нас MVP (в той мере в какой это возможно) и обычные junit тесты, потом gwtmockito и вот эта библиотечка. Работаем вообще на 2.4.0 по той простой причине, что много самописных компонентов и переезжать на новую версию больно.
Да, не все можно сымитировать, согласен, но с другой стороны такое и с классическими GWT тестами скорее всего не протестишь. Никто не спорит с тем, что нужно придерживаться разделения, но не всегда получается.
Например я активно использую SelectionModel из GWT поставки, но при этом её нельзя использовать в junit тестах, ибо внутренняя реализация использует Scheduler.get, который нельзя замокать никакими стандартными средствами. Здесь эта библиотечка подходит идеально.
Я всегда считал, что моков RPC сервисов вполне достаточно, а все остальное тестируется server side unit тестами (если конечно не пихать всю реализацию прямо в RPC сервлеты GWT)
Мы используем эту штуку как часть всей системы тестирования. То есть у нас MVP (в той мере в какой это возможно) и обычные junit тесты, потом gwtmockito и вот эта библиотечка. Работаем вообще на 2.4.0 по той простой причине, что много самописных компонентов и переезжать на новую версию больно.
Sign up to leave a comment.
Тестирование GWT приложений архитектуры MVP