Obsah
Agilní programování (Agile Programming, AP) je relativně novým přístupem k vývoji software.
-
Není to jedna metodika, přesný návod, jak systém navrhnout a realizovat.
-
Je to spíše přístup, "filozofie", do které je třeba dodat konkrétní postupy pro jednotlivé úkony vývoje.
-
Označení Agilní programování bylo poprvé zavedeno skupinou autoritativních odborníků (praktiků) na SW metodiky.
-
Zastánci AP se sdružili při sestavení manifestu AP, formulující jeho hlavní zásady.
„We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: “
„Individuals and interactions over processes and tools“
„Working software over comprehensive documentation“
„Customer collaboration over contract negotiation“
„Responding to change over following a plan “
„That is, while there is value in the items on the right, we value the items on the left more.“
Motivací pro AP byla především řada neúspěchů při budování rozsáhlých softwarových děl a řízení realizačních projektů.
-
Projekty trvaly déle, než se předpokládalo.
-
Stály více peněz.
-
Objevovala se negativa typu "hraní na úspěch/výsledek" a nikoli výsledek sám.
-
K cíli se nešlo přímočaře, produkovaly se dále nevyužité (nevyužitelné) artefakty, věci do zásoby.
-
Mezi zadavatelem (zákazníkem) a tvůrcem byla propast (formalizmus místo spolupráce).
-
Vytvořené produkty pak často neodpovídaly aktuální potřebě...
Namísto jednorázového (obvykle složitého) jednání o smlouvách s přesnou (a v podstatě statickou) specifikací zadání:
Na vývoj software má vliv mnoho faktorů, které se neustále mění (zadání, návrh, technologie, trh, složení týmu apod.). Obecně lze říci, že změna je jedinou konstantou vývoje software. Problémem vývoje softwaru je schopnost úspěšného zvládnutí těchto změn za přijatelné náklady.
Od ostatních metodik se XP odlišuje v následujících vlastnostech:
- Automatizované testování
-
testy jsou tvořeny před samotnou tvorbou zdrojového textu za účelem následného ověření skutečného pokroku ve vývoji softwaru z hlediska jeho požadované funkcionality (testy navrhuje zákazník) a architektury programového modulu (testy navrhuje programátor).
- Verbální komunikace
-
společně s testy a zdrojovým textem slouží ke sdělování systémové struktury a záměru projektu.
- Intuice
-
Postupy, které podporují intuici programátorů a dlouhodobé zájmy projektu (testování, refaktorizace, integrace apod.).
- Komunikace
-
Udržení řádných komunikačních toků ovlivňuje kvalitu jednotlivých postupů XP (testování modulů, párové programování, stanovení metrik apod.).
- Jednoduchost
-
Vývoj software je řízen zásadou, že je lepší udělat jednoduchou věc dnes, s vědomím, že zítra bude možná nutné provést další změnu, spíše než udělat složitější změnu dnes, která nemusí být uživatelem využita. Jednoduchost a komunikace jsou spolu komplementární. Čím více tým komunikuje, tím je mu jasnější co přesně má dělat. Naopak čím je jednodušší systém, tím méně potřebujeme komunikovat.
- Odvaha
-
Členové týmu jsou ochotni experimentovat s vyšším rizikem a ziskem.
- Hraní na výhru
-
představuje soustředění práce týmu na kvalitu vyvíjeného produktu, nikoli na zbytečné alibistické činnosti, kdy tým pracuje „podle předpisů“ (mnoho papírů a porad), aby se tzv. „neprohrálo“.
- Konkrétní experimenty
-
kdy všechna abstraktní rozhodnutí by měla být převedena do řady experimentů, které jsou následně otestovány.
- Práce v souladu s lidskými instinkty
-
a nikoli proti nim představuje práci s krátkodobými zájmy lidí, kteří se rádi učí, vyhrávají, komunikují s ostatními apod.
- Cestování nalehko
-
představuje hodnotné a účinné nástroje vývoje softwaru, které tvoří především testy a zdrojový text.
-
Plánovací hra stanoví šíři zadání následující verze software pomocí kombinace obchodních priorit a technických odhadů.
-
Malá verze představuje rychlé uvedení jednoduchého systému do provozu. Následně jsou uvolňovány malé přírůstky systému ve velmi krátkých cyklech.
-
Metafora pomáhá všem v projektu pochopit základní prvky systému a vztahy mezi nimi na základě jednoduchého přirovnání.
-
Jednoduchý návrh u něhož je nadbytečná složitost ihned odstraněna v okamžiku jejího zjištění z návrhu.
-
Testování představuje činnost programátorů a zákazníků, kdy programátoři testují zdrojový text z hlediska jeho programových vlastností, aby mohli pokračovat v jeho dalším psaní, a kdy uživatelé otestují funkcionalitu modulu, která je úspěšným provedením testu dokončena.
-
Refaktorizace představuje restrukturalizaci systému s cílem zdokonalení jeho nefunkčních kvalit (pružnost, zjednodušení) bez vlivu na jeho chování.
-
Párové programování představuje vývoj zdrojového textu dvěma programátory na jednom počítači.
-
Společné vlastnictví
-
Nepřetržitá integrace - okamžitá integrace dokončeného otestovaného přírůstku do systému.
-
40 hodinový týden plus se nepracuje nikdy přesčas dva týdny za sebou.
-
Zákazník na pracovišti - odpovídá na otázky programátorů při vývoji software.
-
Standardy pro psaní zdrojového textu
- Plánování
-
představuje stanovení termínu programátory společně se zákazníky na základě postupu plánovací hry. Do uvolnění první verze by mělo trvat mezi dvěma až šesti měsíci.
- Smrt
-
představuje stav systému, kdy je software neschopen své existence z důvodu neekonomického rozšíření jeho funkcionality, entropie (tendence k většímu počtu chyb). Zákazníci i manažeři by měli souhlasit s ukončením údržby systému s tím, že se snaží identifikovat příčiny zániku systému.
Netýká se jen programování, je to obecný princip vývoje či realizace čehokoli.
Snahou je produkovat co nejjednodušeji, bez zbytečností, bez nadbytečností, s minimem chyb.
KISS přístup patří do základního arzenálu Agilního programování.
Ideovými předchůdci principu jsou např.:
-
tzv. Occamova břitva (Occam's Razor)
-
Klasický způsobe vývoje SW předpokládá testování jako následnou fázi - testy se píší a spouštějí až po návrhu software
-
To je však paradoxní, protože návrh testů vychází - stejně jako návrh vlastního kódu - ze specifikace a to dokonce přímočařeji. Test je přímý odraz specifikace, protože programovým kódem hlídá chování, které je specifikací očekáváno.
-
Programování řízené testy proto předřazuje návrh a implementaci testů před vývoj vlastního SW.
-
Jde o metodiku vývoje samotného SW, ne testů.
-
Napsat test - na základě specifikace (požadavků) reprezentovaných např. případy užití (usecases).
Test bude používat samotný kód prostřednictvím rozhraní.
-
Napsat kód - aby splnil specifikaci a komunikoval se světem pomocí rozhraní (API).
-
Spustit automatizované testy.
-
V případě chyb kód přeprogramovat (refactoring) a
-
spustit testy znovu.
některé převzaty z Wikipedie, hesla Test-driven Development:
-
testovat během celého životního cyklu projektu,
-
vyvíjet testy ještě před samotným kódem,
-
(kontinuálně) testovat všechny artefakty programu,
-
testováním odhalovat příčiny chyb a nepřekrývat je,
-
při testování používat přitom jednoduché a efektivní nástroje a
-
testování zahrnout po všech stránkách do vývoje
Typická Java EE aplikace s Enterprise JavaBeans (EJB):
-
klientské webové rozhraní,
-
to komunikuje se servlety a stránkami JSP, JSF...
-
aplikační logika realizovaná Session Beans (mezi tím příp. fasáda)
-
komponenty Entity Beans s perzistencí zajištěnou relační databází.
-
Namísto EJB se dnes často používá objektově-relační mapování běžných (POJO) objektů,
-
pro řízení na vyšších vrstvách se využívají webové rámce.
- Type 1: code logic unit testing
-
Probably the best strategy for these tests is to use a Mock Objects type framework.
- Type 2: integration unit testing
-
These tests will exercise the interactions with the container. (Cactus)
- Type 3: functional unit testing
-
These unit tests will let you test the returned values from your server code. This is for example HttpUnit (Note that HttpUnit also performs standard functional testing - as opposed to functional unit testing -, which let you test full use cases - a login use case for example, which is comprised of several requests/responses).
Nástroj JUnit, http://junit.org
public class StackTest extends JUnit.framework.TestCase {
private Stack st;
public StackTest(String testCaseName) {
super(testCaseName);
}
// vytvoří přípravek, nastaví prostředí každého testu
public void setUp() {
st = new Stack(10);
}
// testuje prázdnost právě vytvořeného zásobníku
public void testEmptyAfterCreation() {
assertTrue("Stack should be empty after creation.",
st.isEmpty());
}
// testuje neprázdnost zásobníku po vložení prvku
public void testPushPopEquals() {
st.push("something");
assertEquals("What was pushed, must be popped...",
"something", st.pop());
}
...
// uklidí po testu, je-li třeba
public void tearDown() { }
}
Integrovaná do všech reálně používaných vývojových nástrojů:
Dnes se vždy předpokládá, že ke KAŽDÉMU netriviálnímu projektu existují testy.
V netriviálních projektech, tam, kde se integruje např. jednou za den, není možné pokaždé spouštět všechny testy.
Např. Maven pracuje hojně s protokoly (reports) vč. testovacích.
Většina testovacích nástrojů umí kromě "transientního" zobrazení průběhu výsledky testu zaznamenat.
Elementárně např. ve dvojici nástrojů - Ant tasks -
junit (otestuje),
junitreport
(zaformátuje
protokoly):
<junit printsummary="yes" haltonfailure="yes">
<classpath>
<pathelement location="${build.tests}"/>
<pathelement path="${java.class.path}"/>
</classpath>
<formatter type="plain"/>
<test name="my.test.TestCase" haltonfailure="no" outfile="result">
<formatter type="xml"/>
</test>
<batchtest fork="yes" todir="${reports.tests}">
<fileset dir="${src.tests}">
<include name="**/*Test*.java"/>
<exclude name="**/AllTests.java"/>
</fileset>
</batchtest>
</junit>
<junitreport todir="./reports">
<fileset dir="./reports">
<include name="TEST-*.xml"/>
</fileset>
<report format="frames" todir="./report/html"/>
</junitreport>
DBUnit – rozšíření JUnit (http://dbunit.sf.net)
Používá se JUnit a nadstavby, resp. obdobné nástroje:
- TestNG
-
moderní, na anotacích založený systém, lepší než junit díky jemnější organizovatelnosti testů (skupiny testů, parametry, protokolování...)
- djunit
-
http://www.fi.muni.cz/~tomp/djunit
rozšíření junit s možností "krmit" testy daty ze souborů, proudů, zdrojů (resources)
- junit v4
-
nová verze JUnit s podporou anotacemi
- Artima SuiteRunner
-
http://www.artima.com/suiterunner/index.html
Reporter: Collect and present test results in a highly customizable way to the user. Examples are text, graphics, web pages, database output, CSV files, XML, and email alerts. Runpath: Load classes for your tests from anywhere with this easy to configure list filenames, directory paths, and/or URLs. Recipe File: Capture and save the properties of a run of a particular suite of tests in a file for easy reuse.
Systém Apache Cactus, http://jakarta.apache.org/cactus/
Nástroj JWebUnit umožní virtuálně "klikat" po webové aplikaci a srovnávat výstupy od serveru s očekávanými.
public class JWebUnitSearchExample extends WebTestCase {
...
public void setUp() {
getTestContext().setBaseUrl("http://www.google.com");
}
public void testSearch() {
beginAt("/"); // na kterém URL začít
setFormElement("q", "httpunit"); // co na stránce vybrat
submit("btnG"); // jaké tlačítko stisknout
clickLinkWithText("HttpUnit"); // kam kliknout
assertTitleEquals("HttpUnit"); // co má od serveru přijít
assertLinkPresentWithText("User's Manual");
}
}
Nástroj Marathon umožní virtuálně "klikat" po GUI aplikaci a srovnávat výstupy od serveru s očekávanými.
-
obecně se testuje těžko…
-
většinou na principu zachycení či naskriptování uživatelských akcí nad GUI
-
na jednodušší v Javě lze použít "robota" pro javové GUI
public class JWebUnitSearchExample extends WebTestCase {
...
public void setUp() {
getTestContext().setBaseUrl("http://www.google.com");
}
public void testSearch() {
beginAt("/"); // na kterém URL začít
setFormElement("q", "httpunit"); // co na stránce vybrat
submit("btnG"); // jaké tlačítko stisknout
clickLinkWithText("HttpUnit"); // kam kliknout
assertTitleEquals("HttpUnit"); // co má od serveru přijít
assertLinkPresentWithText("User's Manual");
}
}
Mockrunner umí pomocí mock-objektů testovat JDBC, webové (servletové) aplikace i EJB.
public class RedirectServletTest extends BasicServletTestCaseAdapter {
protected void setUp() throws Exception {
super.setUp();
createServlet(RedirectServlet.class);
}
public void testServletOutputAsXML() throws Exception {
addRequestParameter("redirecturl", "http://www.mockrunner.com");
doPost();
Element root = getOutputAsJDOMDocument().getRootElement();
assertEquals("html", root.getName());
Element head = root.getChild("head");
Element meta = head.getChild("meta");
assertEquals("refresh", meta.getAttributeValue("http-equiv"));
assertEquals("0;URL=http://www.mockrunner.com",
meta.getAttributeValue("content"));
}
}
Apache JMeter 100% pure Java desktop application designed to load test functional behavior and measure performance.
Nejen pro webové aplikace, ale i např. databázové (SQL) dotazy, JMS komunikaci, FTP přenosy...
-
Can load and performance test HTTP and FTP servers as well as arbitrary database queries (via JDBC)
-
Complete portability and 100% Java purity
-
Full multithreading framework allows concurrent sampling by many threads and simultaneous sampling of different functions by seperate thread groups.
-
Caching and offline analysis/replaying of test results.
Highly Extensible: o Pluggable Samplers allow unlimited testing capabilities. o Several load statistics may be choosen with pluggable timers . o Data analysis and visualization plugins allow great extendibility as well as personalization. o Functions (which include JavaScript) can be used to provide dynamic input to a test o Scriptable Samplers (BeanShell is supported in version 1.9.2 and above)
