Какво да тествам с Robolectric?

Струва ми се, че фундаментално не разбирам целта на Robolectric. Вече седмица се боря с него и досега получаването на ново съобщение за грешка се счита за напредък. Мога да тествам някои основни неща като статични изгледи в дейност, но когато нещо по-сложно влезе в игра, нещата просто се разпадат. Трябваше да разширя Robolectric, за да поддържа библиотеки на трети страни с определени параметри, ленти за действие на Appcompat и много други неща, което отнемаше изключително много време и не беше документирано никъде, а нещата напредват с почти ледникови темпове. Започвам да си мисля, че го използвам по грешен начин и просто не трябва да прави това, което искам.

Общата логика на приложението е доста ясна, така че всъщност няма много за тестване на единици, най-сложните неща са в потребителския интерфейс и отдалечените API извиквания. Трябва ли Robolectric просто да направи модулното тестване за Android по-малко болезнено, отколкото с JUnit, защото може да работи на JVM и поддържа няколко Android класа? Може би рамка за тестване на поведение на черна кутия като Espresso би била по-подходяща за моите нужди? Но ние използваме непрекъсната интеграция и Robolectric беше хубав и лесен за настройка, за да изпълнява тестове на CI сървъра, и бих искал да го запазим така.

За какво използвате Robolectric? Много публикации в блогове го препоръчват за „тестване на жизнения цикъл на активността“, но тъй като аз също съм доста нов в света на Android, не разбирам наистина целта му, особено след като приложението, което тествам, е само портретно . Може ли някой да даде общ преглед на това за какво използвате Robolectric и как го правите, за предпочитане с примери на код и да обясни защо и как тези тестове са важни?


person p4sh4    schedule 08.12.2014    source източник
comment
Мисля, че ще бъдете по-добре в борсата за програмисти. Става въпрос за концептуални въпроси.   -  person cheffe    schedule 08.12.2014
comment
Благодаря за съвета, но има донякъде подобен въпрос там няма много подходящи отговори и е затворен. Тук питам повече за конкретни случаи на употреба, които хората действително използват с примери за код.   -  person p4sh4    schedule 09.12.2014


Отговори (1)


Използваме го за:

  • модулно тестване: всички компоненти от парсери и помощни програми до контролери и презентатори
  • тестване за интегриране/приемане: бизнес логиката на приложението, на екран (което попада в тестване за интегриране и/или приемане)

Ние не го използваме за (и открихме, че е трудно да го използваме за тези):

  • тестване на мрежовия слой (извършваме всички тестове, като инжектираме тестовите данни по същия начин, по който би го направил мрежовият слой; парсерите се тестват отделно)
  • потребителят преминава през различни екрани

Ако търсите повече от последното, може би Espresso/Robotium са по-подходящи за вашите нужди. И вие абсолютно можете да ги стартирате като част от вашия CI тръбопровод, но ще трябва да инвестирате известно време в настройка или интегриране с нещо като Appurify.

Ако ви е много трудно да пишете вашите тестове, това може да се дължи повече на начина, по който е проектирано вашето приложение, отколкото на начина, по който използвате robolectric. Вижте и моя отговор тук, може да ви помогне: Писане на тестове за приемане на Android с robolectric: как може да се направи?

person Alex Florescu    schedule 09.12.2014
comment
Добър отговор, благодаря! Можете ли да разясните малко повече относно частта за потребителските потоци - използвам Robolectric, за да тествам дали правилната дейност/фрагмент започва при натискане на бутон или събитие, попада ли в бизнес логиката на приложението, за категория на екрана или потребителски потоци категория? Бихте ли могли да дадете пример за тестовете на контролера и презентатора? - person p4sh4; 10.12.2014
comment
Лесно е да се тества, че за някакво действие на екрана ще се отвори друг екран. Бих препоръчал да не тествате два екрана наведнъж (напр. тестов екран A, тестов преход към екран B, след това тестов екран B), което може да бъде валиден потребителски поток. Това е по-добре да се направи в UI тестове. - person Alex Florescu; 10.12.2014
comment
О, да, не тествам два екрана наведнъж. Тестът все още не изглежда да е истински модулен тест, защото понякога включва няколко метода от класа, но определено трябва да ги огранича до максимум една дейност/фрагмент. - person p4sh4; 10.12.2014