Не стоит.
Сам пользователь BlackBerry(ну хотел я себе раскладушку с вайфай).
Захотел написать простенькое приложении и… не получилось(может я и криворукий, но под андроид себе что-то да получилось).
Элементарно не получилось установить плагин для Eclipse.
Из плюсов BB — шарик, для меня ну очень удобно. Не знаю как для остальных.
Мы с вами говорим об одних и тех же вещах, но на разных языках. Извините за некоторое недопонимание может быть, но в любом случае больщое спасибо за разъяснение.
Один и тот же учебник в 2009 году стоит $10 в следующем году $11 и инфляция составляет ровно 10%. Как ни крути. Новые учебники — новый продукт. А график можно вывернуть как угодно, допустим сказать, что это парабола и в следующем году это будет уже 100 Тбит/c.
ну когда же он уже выйдет! 2014 год вроде как обозначен, очень надеюсь что сроки не изменятся(только в меньшую сторону). После просмотра «коротулек» от симпалс стал пристально следить за их блогом
могу. обычно мок — какой-то объект, который сложно создать просто так. Например сущность общения с бд(выражаюсь расплывчато ибо в разных подходах по разному), либо очень много зависимостей, а в тесте нужна только маленькая часть функционала.
Допустим пример — у нас есть класс, метод которого принимает строку, разбирает ее и сохраняет в БД. Для этого у нас есть специальные сущности — парсер и «сохраняльщик».
Мы создаем моки этих сущностей. и вот тут происходит некоторое изменение в написании теста. Нам ведь не нужно тестировать, что парсер именно распарсит входную строку это должно отражаться в тестах парсера. Мы просто должны убедиться что вызван данный метод у парсера. То же самое и с «сохраняльщиком».
честно. сочувствую вам, вы работаете с продуктом который не похож на другие(хотя наверное должен) и каждый шаг как у скалолаза — неизвестно куда выведет. Требуйте надбавки!
ну вот!) вы уже все написали что вам необходимо! в тесте вы будете создавать дто, и передавать на ваш слой работы с данными, и анализировать, что на выходе будет нужный вам запрос. и наоборот. Это юнит-тестирование.
Однако тут для полного цикла тестирования придется написать и интеграционные тесты:
подавать на вход дтошки, скажем на запись или обновление и анализировать, что данные изменились.
ну вот ни разу с ним не работал. И что-то, если быть честным, не хочется. Тогда выход действительно один — моки. Хотя они и несколько усложняют написание тестов. С более привычными(относительно конечно) неплохо работает как раз метод с базой в памяти.
Сам пользователь BlackBerry(ну хотел я себе раскладушку с вайфай).
Захотел написать простенькое приложении и… не получилось(может я и криворукий, но под андроид себе что-то да получилось).
Элементарно не получилось установить плагин для Eclipse.
Из плюсов BB — шарик, для меня ну очень удобно. Не знаю как для остальных.
Очень пригодится в ближайшем будущем!
посмотрите, может поможет:
h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-127-24^1352_4000_100__
(После крышечки тоже url, неправильно вставил наверное)
Зависит от вас. Не агитирую за юнит тесты.
Допустим пример — у нас есть класс, метод которого принимает строку, разбирает ее и сохраняет в БД. Для этого у нас есть специальные сущности — парсер и «сохраняльщик».
Мы создаем моки этих сущностей. и вот тут происходит некоторое изменение в написании теста. Нам ведь не нужно тестировать, что парсер именно распарсит входную строку это должно отражаться в тестах парсера. Мы просто должны убедиться что вызван данный метод у парсера. То же самое и с «сохраняльщиком».
тема отдельной статьи)
Однако тут для полного цикла тестирования придется написать и интеграционные тесты:
подавать на вход дтошки, скажем на запись или обновление и анализировать, что данные изменились.