Расскажите подробнее или дайте ссылку, как испольовать CodeFirst (как я полагаю из EF) для того чтобы «загружать тестовые/боевые данные, откатывать схему табллиц.»
Как уже подсказал Elufimov, использование SpecFlow+WebDriver или WebDriver c PageObjects, PageElements как раз и есть способ правильной разработки тестов. Я думаю поправить статью и сразу указать на эти технологии вместо записи тестов в Selenium IDE.
Да, вы правы. Использование SpecFlow+WebDriver вместо записи действий в Selenium IDE серьезно сократит объем работы для разработчиков.
Это как раз и есть та техника, которая мне была нужна, для уменьшения объема работ по поддержинию тестов, спасибо за совет.
Надо состредоточиться на таких сценариях, чтобы они не сыпались сразу все, как только чуть-чуть изменится фронт.
Еще раз повторю: разработчики обожают и умеют писать код, который не сыпится, как толкь чуть-чуть что-то поменятеся. И тесты надо тоже проектировать с умом.
к сожалению в конфигурации с WebDriver есть следующий недостаток: если записать тест в Selenium IDE, и попытаться его экспортировать в C#, то многие шаги не будут экспортированы. Будет написано что-то вроде «Нет шаблона для экспорта». В таких случаях надо будет самому писать этот C# код, который так же надо отлаживать.
Я считаю что быстрый и уже протестированный создателями Selenium экспорт в C# для RemoteControl испольозовать лушче, несмотря на то, что придется запускать Remote control server
Не слогласен.
Во-первых, тесты это часть результата работы разработчика. Ведь никого не смущает, что приходится писать и поддерживать много кода.
Во-вторых, для того чтобы обуздать объем кода используются различные технологии, вроде библиотек и использования ООП. То же самое с тестами их не надо бездумно копипасить, надо с наименьшим кол-вом тестов затронуть наибольшее кол-во функционала.
В-третьих, поддерживать тесты могут и тестировщики, а SQL скрипты с данными для тестов будут меняться редко.
Так что плюсы все равно остануться, просто если ваше приложение большое и требует много тестов, которые сложно поддерживать, это не занчит, что если прогонять все тесты в ручную разработка пойдет быстрее с тем же уровнем качества.
Сейчас наша система находится в начале разработки, поэтому тестов немного, всго несколько штук, и работают они тоже быстро, порядка 10 секунд на тест при 10-20 шагах в тесте
Конечно.
На сайте проекта есть ссылка на SVN:
code.google.com/p/deezapps-widgets/source/checkout
Можно скачать там.
В этом проекте есть необходимые исходники и как раз показаны основные варианты исползьования.
Необходимые исходники это файлы attrs.xml и HorizontalPager.java ( может быть еще нужен PagerControl.java, но в своем проекте я обошелся без него)
Остальные файлы нужны для демонстрации возможностей
Конечно.
На сайте проекта есть ссылка на SVN: code.google.com/p/deezapps-widgets/source/checkout
Можно скачать там.
В этом проекте есть необходимые исходники и как раз показаны основные варианты исползьования.
Необходимые исходники это файлы attrs.xml и HorizontalPager.java ( может быть еще нужен PagerControl.java, но в своем проекте я обошелся без него)
Остальные файлы нужны для демонстрации возможностей
Согласен, что при проектировании можно расположить UI и логику в разных классах и передавать имитации в тестируемый класс логики через конструктор или еще как-то.
Но с использованием RoboGuice все это делается за меньшее количество строк кода. Самый яркий пример, мне не надо передавать контекст во все мои классы с логикой, я его получаю через RoboGuice.
согласен, что из-за этого мое приложение увеличиться на 200кб и будет на долю секунды медленнее работать. Но я считаю что я получаю больше в виде сокращения объемов моего кода и повышения его читаемости.
Кстати, а как вы в своих тестах имитируете окружение при тестах классов с логикой?
По поводу хранения классов, полагаю стоит делать пакет Activity, в котором располагать пакеты для каждой активности. Таки образом не будет проблем с ориентацией.
Признаю, что я был не прав когда говорил, что нельзя тестировать логику без UI. Но способы имитации окружения, вроде передачи имитаций через конструктор выглядят для меня очень неудобными. Слишком много нужно дополнительного кода, по сравнению с использованием Dependency Injection
Да, основная задача RoboGuice это Dependency Injection.
Так же я его использую для инициализации экземпляров классов.
Он действительно использует рефлексию.
Вот только это нельзя назвать «довольно затратным». Видимых просадок производительности нет. Лишняя 0.1 секунды при старте активности это не затратно.
Никак не могу понять почему приложение станет громоздким. Если у меня 20 активностей, которые сосредоточены в 20 пакетах, это разве громоздко? Какой критерий при определении громоздкости вы используете?
Как мне в тесте отделить UI от логики? Я знаю как это можно сделать через Dependency Injection. Расскажите другой способ.
И вообще, расскажите мне, какую выгоду я получу, если откажусь от MVP и буду использовать один класс на одну активность? Дайте оценку на сколько быстрее будет работать мое приложение. Укажите в чем будет выражаться то, что такое приложение менее громоздко.
Тестировать UI вместе с логикой — плохо, потому что нельзя разрабатывать логику и UI по одтельности.
Ктому же встроенный в SDK JUnit Test Framework обладает существенным недостаткам: он не поддерживает изоляцию тестов. То есть первый тест поднимает процесс приложения и тестирует первую активность. Второй тест берет приложение в том состоянии, которое осталось после первого теста и тестирует вторую активность. Если у вас есть в приложении многопоточноть то вы будете полуать завершение потоков из перой активности во время тестирования второй. Так же некторые события UI задерживаются и приходят во вторую активность.
Поэтому я отказался от тестирования UI встроенным JUnit-ом.
Даже если это большое приложение, то в проект приложения на одну активность надо добавить 1 интерфейс для View, 1 presenter, 1 интерфейс для модели и 1 класс модели.
Конечно файлов 5 файлов больше чем один, но кода в этих файлах больше всего лишь на 5-10%
Это не огромное кол-во файлов, с ним можно нормально работать. Поскольку эти файлы относятся к одной активности и находятся в одном пакете, нет никаких проблем с поиском нужного файла.
Еще раз скажу, что на скорости работы это заметно не скажется.
Зато в большом приложении гораздо важнее возможность разрабатывать части приложения, когда еще не готовы другие части, которые необходимы для разработки первой части.
Необходимые части можно заменить в тестах имитациями и отладить полностью свою часть.
Для менеджера проекта это очень важное свойство MVP, потому что менеджер получает гораздо большее пространство для маневра при распределении ресурсов по задачам.
И в конце концов это позволяет сократить срок разработки проекта.
Поэтому в большом проекте использование MVP наоборот принесет еще больше пользы.
Спасибо за ссылки на тестовые framework-и, я их обязательно посмотрю.
Но польза от тестирования UI принебрежима мала по сравнению с возможностью тестировать части приложения изолированно от других, а это можно делать и через встроенный в Eclipse JUnit.
Если тестировать приложение через UI, то нужно уже готовое приложение. Получается нельзя отладить код движка, пока не готов UI для него. Так же нельзя поручать разработку движка и UI разным людям, потому что пока не готов UI разработчик движка даже не может приступить к работе, потому что не сможет запустить свой движок.
Использование MVP решает все эти проблемы.
Скорость разработки и качество возрастают гораздо значительнее чем увеличивается размер программы.
P.S.
Не согласен что отказ от MVP сделал бы мое приложение намного меньше. В мое приложение добавилось 200кб библиотек для RoboGuice. Но в остальном MVP требует только 5-10% увеличение кода что не является критичным для работы программы.
У меня есть мобильное приложение, сделанное с использованием MVP.
Если отбросить 550кб звукового файла, то ее размер примерно 250 кб.
Без использования MVP и вспомогательных технологий, полагаю ее размер был бы 50 кб.
Итого.
1. Увеличение объема на 200 кб из-за дополнительных библиотек (а не в 5 раз, как может показаться)
2. Приложение работает на эмуляторе и на моем Galaxy S работает быстро, во всяком случае я быстрее могу настроить необходимые параметры, чем в других аналогичных программах. Расходов по скорости нет.
То есть расходы 200 Кб.
Зато доходы:
1. Качественная разработка. Для написания движка я написал порядка 30 тестов, и при отладке часто через тесты обнаруживал, что сломал предыдущую часть алгоритма.
2. Без тестов у меня бы ушло примерно в два-три раза больше времени на полную отладку алгоритма, а ошибки, при этом, находили бы пользователи, что очень плохо.
То есть доходы примерно двоекратное сокращение времени разработки и репутация качественного софта.
Не согласен с тем, что не надо плодить лишние интерфейсы.
Как показывает практика, рост размеров проекта и замедление работы приложения, при использовании MVP, на глаз заметить не возможно.
А вот скорость разработки и качество очень даже заметны.
PowerMock я не пробовал использовать.
Но думаю попробовать в следующем проекте, потому что у AndroidMock есть несколько серьезных недостатков, да и не развивается он.
То что вы описали это не полный MVP.
В такой ситуации у View или Presenter-а нет интерфейса, который можно симитировать.
А контент провайдер не является моделью, потому что туда нельзя добавить методы бизнес-логики, которые обычно и живут в модели.
Контент провайдер можно рассматривать как репозиторий, который достает модель из БД.
Поэтому я и затеял этот цикл статей, чтобы показать как существующие в Android компоненты увязать в MVP.
Это как раз и есть та техника, которая мне была нужна, для уменьшения объема работ по поддержинию тестов, спасибо за совет.
Еще раз повторю: разработчики обожают и умеют писать код, который не сыпится, как толкь чуть-чуть что-то поменятеся. И тесты надо тоже проектировать с умом.
Я считаю что быстрый и уже протестированный создателями Selenium экспорт в C# для RemoteControl испольозовать лушче, несмотря на то, что придется запускать Remote control server
Во-первых, тесты это часть результата работы разработчика. Ведь никого не смущает, что приходится писать и поддерживать много кода.
Во-вторых, для того чтобы обуздать объем кода используются различные технологии, вроде библиотек и использования ООП. То же самое с тестами их не надо бездумно копипасить, надо с наименьшим кол-вом тестов затронуть наибольшее кол-во функционала.
В-третьих, поддерживать тесты могут и тестировщики, а SQL скрипты с данными для тестов будут меняться редко.
Так что плюсы все равно остануться, просто если ваше приложение большое и требует много тестов, которые сложно поддерживать, это не занчит, что если прогонять все тесты в ручную разработка пойдет быстрее с тем же уровнем качества.
Конечно.
На сайте проекта есть ссылка на SVN:
code.google.com/p/deezapps-widgets/source/checkout
Можно скачать там.
В этом проекте есть необходимые исходники и как раз показаны основные варианты исползьования.
Необходимые исходники это файлы attrs.xml и HorizontalPager.java ( может быть еще нужен PagerControl.java, но в своем проекте я обошелся без него)
Остальные файлы нужны для демонстрации возможностей
На сайте проекта есть ссылка на SVN:
code.google.com/p/deezapps-widgets/source/checkout
Можно скачать там.
В этом проекте есть необходимые исходники и как раз показаны основные варианты исползьования.
Необходимые исходники это файлы attrs.xml и HorizontalPager.java ( может быть еще нужен PagerControl.java, но в своем проекте я обошелся без него)
Остальные файлы нужны для демонстрации возможностей
code.google.com/p/deezapps-widgets/
Мне очень понравилось что для его использования вообще не надо писать java кода, только задать разметку в XML:
вот весь код чтобы сделать две перелистываемые странички. Каждая страница в примере это TextView, но можно заменить на свой Layout.
<com.deezapps.widget.HorizontalPager
android:layout_width=«fill_parent»
android:layout_height=«wrap_content»>
<TextView android:text=«Text 1»/>
<TextView android:text=«Text 2»/>
</com.deezapps.widget.HorizontalPager>
Библиотек подключать не надо, весь код идет одним Java файлом.
примеры я копировал кусками из своего проекта и похоже кое-что упустил.
Сейчас поправлю.
Но с использованием RoboGuice все это делается за меньшее количество строк кода. Самый яркий пример, мне не надо передавать контекст во все мои классы с логикой, я его получаю через RoboGuice.
согласен, что из-за этого мое приложение увеличиться на 200кб и будет на долю секунды медленнее работать. Но я считаю что я получаю больше в виде сокращения объемов моего кода и повышения его читаемости.
Кстати, а как вы в своих тестах имитируете окружение при тестах классов с логикой?
По поводу хранения классов, полагаю стоит делать пакет Activity, в котором располагать пакеты для каждой активности. Таки образом не будет проблем с ориентацией.
Признаю, что я был не прав когда говорил, что нельзя тестировать логику без UI. Но способы имитации окружения, вроде передачи имитаций через конструктор выглядят для меня очень неудобными. Слишком много нужно дополнительного кода, по сравнению с использованием Dependency Injection
Так же я его использую для инициализации экземпляров классов.
Он действительно использует рефлексию.
Вот только это нельзя назвать «довольно затратным». Видимых просадок производительности нет. Лишняя 0.1 секунды при старте активности это не затратно.
Никак не могу понять почему приложение станет громоздким. Если у меня 20 активностей, которые сосредоточены в 20 пакетах, это разве громоздко? Какой критерий при определении громоздкости вы используете?
Как мне в тесте отделить UI от логики? Я знаю как это можно сделать через Dependency Injection. Расскажите другой способ.
И вообще, расскажите мне, какую выгоду я получу, если откажусь от MVP и буду использовать один класс на одну активность? Дайте оценку на сколько быстрее будет работать мое приложение. Укажите в чем будет выражаться то, что такое приложение менее громоздко.
Тестировать UI вместе с логикой — плохо, потому что нельзя разрабатывать логику и UI по одтельности.
Ктому же встроенный в SDK JUnit Test Framework обладает существенным недостаткам: он не поддерживает изоляцию тестов. То есть первый тест поднимает процесс приложения и тестирует первую активность. Второй тест берет приложение в том состоянии, которое осталось после первого теста и тестирует вторую активность. Если у вас есть в приложении многопоточноть то вы будете полуать завершение потоков из перой активности во время тестирования второй. Так же некторые события UI задерживаются и приходят во вторую активность.
Поэтому я отказался от тестирования UI встроенным JUnit-ом.
Конечно файлов 5 файлов больше чем один, но кода в этих файлах больше всего лишь на 5-10%
Это не огромное кол-во файлов, с ним можно нормально работать. Поскольку эти файлы относятся к одной активности и находятся в одном пакете, нет никаких проблем с поиском нужного файла.
Еще раз скажу, что на скорости работы это заметно не скажется.
Зато в большом приложении гораздо важнее возможность разрабатывать части приложения, когда еще не готовы другие части, которые необходимы для разработки первой части.
Необходимые части можно заменить в тестах имитациями и отладить полностью свою часть.
Для менеджера проекта это очень важное свойство MVP, потому что менеджер получает гораздо большее пространство для маневра при распределении ресурсов по задачам.
И в конце концов это позволяет сократить срок разработки проекта.
Поэтому в большом проекте использование MVP наоборот принесет еще больше пользы.
Спасибо за ссылки на тестовые framework-и, я их обязательно посмотрю.
Но польза от тестирования UI принебрежима мала по сравнению с возможностью тестировать части приложения изолированно от других, а это можно делать и через встроенный в Eclipse JUnit.
Если тестировать приложение через UI, то нужно уже готовое приложение. Получается нельзя отладить код движка, пока не готов UI для него. Так же нельзя поручать разработку движка и UI разным людям, потому что пока не готов UI разработчик движка даже не может приступить к работе, потому что не сможет запустить свой движок.
Использование MVP решает все эти проблемы.
Скорость разработки и качество возрастают гораздо значительнее чем увеличивается размер программы.
P.S.
Не согласен что отказ от MVP сделал бы мое приложение намного меньше. В мое приложение добавилось 200кб библиотек для RoboGuice. Но в остальном MVP требует только 5-10% увеличение кода что не является критичным для работы программы.
Если отбросить 550кб звукового файла, то ее размер примерно 250 кб.
Без использования MVP и вспомогательных технологий, полагаю ее размер был бы 50 кб.
Итого.
1. Увеличение объема на 200 кб из-за дополнительных библиотек (а не в 5 раз, как может показаться)
2. Приложение работает на эмуляторе и на моем Galaxy S работает быстро, во всяком случае я быстрее могу настроить необходимые параметры, чем в других аналогичных программах. Расходов по скорости нет.
То есть расходы 200 Кб.
Зато доходы:
1. Качественная разработка. Для написания движка я написал порядка 30 тестов, и при отладке часто через тесты обнаруживал, что сломал предыдущую часть алгоритма.
2. Без тестов у меня бы ушло примерно в два-три раза больше времени на полную отладку алгоритма, а ошибки, при этом, находили бы пользователи, что очень плохо.
То есть доходы примерно двоекратное сокращение времени разработки и репутация качественного софта.
Для меня доходы многократно превышают расходы.
Как показывает практика, рост размеров проекта и замедление работы приложения, при использовании MVP, на глаз заметить не возможно.
А вот скорость разработки и качество очень даже заметны.
Но думаю попробовать в следующем проекте, потому что у AndroidMock есть несколько серьезных недостатков, да и не развивается он.
В такой ситуации у View или Presenter-а нет интерфейса, который можно симитировать.
А контент провайдер не является моделью, потому что туда нельзя добавить методы бизнес-логики, которые обычно и живут в модели.
Контент провайдер можно рассматривать как репозиторий, который достает модель из БД.
Поэтому я и затеял этот цикл статей, чтобы показать как существующие в Android компоненты увязать в MVP.