Проучвам Дженкинс за моя екип за развитие и започвам да осъзнавам, че това, което искам в края на краищата, е повече изпитване на единиците и по-малко интеграция.
Аз не се интересувам много от интеграцията илис Дженкинс в този момент. Това, което искам най-вече за момента, е да автоматизирам тестването, когато кодът е извършен и да се докладва на разработчиците, когато има проблем.
Дженкинс все още ли е добро решение за това, което се опитвам да постигна?
Ако е така, трябва ли първо да напиша всичките си тестове за единица и после да ги добавите към Дженкинс? Ще се нуждая ли от работа на Дженкинс за всеки тест на отдел или мога ли да комбинирам много тестове за единица в една работа на Дженкинс?
В крайна сметка искам да автоматизирам тестване на PHP, Java (за Android) и Objective-C (iOS).
Благодаря!
db
Отговори:
2 за отговор № 1Да, Дженкинс определено е валидно решение, което ще ви позволи да стартирате тестове за Android и iOS. За Php не мога да кажа, но предполагам, че да.
Дженкинс е основно скрипт, който може да бъдевключен в SCM и изпълнява скриптове, задействани от промените в SCM. Така че, напишете тестовете си, изпълнете ги на машината и просто намерете начин да ги накарате да преминат автоматично през Дженкинс за всеки ангажимент: това е същността на CI.
За Android и iOS се изпълняват задания за създаване иИзпълнението на тестовете е малко трудно, когато имате нужда от изграждането си, за да стартирате емулатор (въпреки че все още можете да прикачите устройство към сървъра си, ако сте достатъчно богат). И има някои плъгини за това, като приставката за емулатор на Jenkins за Android.
0 за отговор № 2
Да, Дженкинс (и практически всеки друг инструмент на CI, който си заслужава името) определено е в състояние да изпълни тестването на единиците.
Отделяне на термините: "интеграцията" е "непрекъсната интеграция" не означава "тест за интеграция" (въпреки че със сигурност можетеизпълнете тези, както и). То се отнася до "интегриране на промените", т.е. checkins. Днес (благодаря!), Отдавна нещата, които не бяха дадени: разработчиците можеха да изминат седмици, без да проверяват, или да проверяват само в лични клонове.Включването на кода в основната линия можеше да отнеме седмици. : изграждане всяка вечер, оттук и терминът "нощно изграждане". Естественото разширение беше да се изгражда непрекъснато, което изискваше сървърът да направи проучване на системата за промени.
С тази гледна точка не можете да провеждате тестове за единица без интеграцията, тъй като ти обикновено трябва първо да се изгради, а след това единица тест. Както бе споменато по-горе: Дженкинс "има силна подкрепа за тестване на устройства: тя лесно може да бъде моделирана като едно работно място на най-високо ниво.
Вижте също по-мощни (и скъпи) животни в това семейство, като Електрически командир.