Ocena i testowanie kodu

Ocena i testowanie kodu Zajęcia 3 Jacek Starzyński, IETiSIP PW

Treść wykładu Wstęp: jakość oprogramowania, a jakość kodu Ocena kodu -- metryki Testowanie testowanie jednostkowe testowanie zależności biblioteki do testowania Ćwiczenia

Jakość oprogramowania Użytkownik: jakość oprogramowania to: zgodność z wymaganiami przydatność (funkcjonalność, łatwość użycia, niezawodność) Wytwórca: ważne są też: konserwowalność rozszerzalność Użytkownik nie widzi kodu, ale z niego korzysta, wytwórca musi kod widzieć (i oceniać)

Ocena kodu - metryki Metryki służą do obiektywnej, ilościowej oceny kodu Można oceniać pojedynczą metodę pojedynczą klasę cały system Najważniejsze są metryki oceniające system ale inne też są istotne

Ocena złożoności metody Metryka SLOC Source Lines Of Code (liczba linii kodu) Metryka CP Comment Percentage (procent komentarzy) Złożoność cyklomatyczna McCabe

Metryka SLOC Pozwala ocenić wielkość systemu...i raczej tylko to Problem z porównywaniem programów w różnych językach #include <stdio.h> int main() { printf("hello World"); return 0; ------------------------------------------------------------------------------ 000100 IDENTIFICATION DIVISION. 000200 PROGRAM-ID. HELLOWORLD. 000300 000400* 000500 ENVIRONMENT DIVISION. 000600 CONFIGURATION SECTION. 000700 SOURCE-COMPUTER. RM-COBOL. 000800 OBJECT-COMPUTER. RM-COBOL. 000900 001000 DATA DIVISION. 001100 FILE SECTION. 001200 100000 PROCEDURE DIVISION. 100100 100200 MAIN-LOGIC SECTION. 100300 BEGIN. 100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS. 100500 DISPLAY "Hello world!" LINE 15 POSITION 10. 100600 STOP RUN. 100700 MAIN-LOGIC-EXIT. 100800 EXIT.

Złożoność cyklomatyczna McCabe Zdefiniowana do oceny programów strukturalnych (w 1976 roku) Złożoność funkcji (metody) określana jest przez liczbę niezależnych ścieżek w grafie przepływu sterowania CC=E V 2 P McCabe sugerował kryterium CC < 10 (E liczba krawędzi, V l. węzłów, P l. Spójnych składowych)

Złożoność cyklomatyczna Start McCabe V V E 4 8 16 CC 1 =? 5 Stop

Ocena złożoności klasy Zestaw metryk CK Zaproponowane w 1993 (IEEE TSE) Chidamber, Kemerer, MIT WMC (Weighted method per class) DIT (Depth of inheritance tree) NOC (Number of children) CBO (Coupling between objects) RFC (Response for class) LCOM (Lack of cohesion of methods)

Weighted Methods per Class WMC jest sumą złożoności wszystkich metod klasy n liczba metod klasy c i złożoność i-tej metody Ocena złożoności klasy = pracochłonności wymaganej do jej utworzenia i pielęgnacji. Wysoka dla klas mocno wyspecjalizowanych n WMC= i=1 c i

Depth of Inheritance Tree DIT jest maksymalną głębokością położenia klasy w drzewach dziedziczenia DIT =max h Klasa może w ogólności (np. C++) dziedziczyć po kilku hierarchiach. DIT jest najgłębszym z możliwych poziomem. Im wyżej klasa dziedziczy, tym jest bardziej złożona i trudniej przewidzieć jej zachowanie.

Number of Children NOC jest liczbą bezpośrednich dzieci klasy w drzewie dziedziczenia Im więcej podklas tym większa powtórna używalność kodu. Zbyt wiele podklas może świadczyć o złym wykorzystaniu dziedziczenia (zła hierarchia?) Im większy NOC tym większy wpływ ma klasa na system i tym trudniej ją testować.

Coupling Between Objects CBO jest liczbą klas związanych z daną przy pomocy innej relacji, niż dziedziczenie Duża wartość CBO świadczy o dużym powiązaniu, co zwykle oznacza kłopoty: mała re-używalność duża wrażliwość na zmiany trudne testowanie

Response For Class RFC moc zbioru wszystkich metod, które mogą być wywołane w odpowiedzi na komunikat wysłany do klasy RFC= {M all i {R i {M zbiór metod klasy {R i zbiór metod wywoływanych przez i-tą metodę klasy Im większe RFC tym bardziej funkcjonalna i bardziej złożona (trudna do testowania) klasa.

Przykład Response For Class public class A { private B ab; public void methoda1() { return ab.methodb1(); public void methoda2(c ac) { return ac.methodc1(); RFC = { methoda1, methoda2, methodb1, methodc1

Lack of Cohesion of Methods LCOM to różnica pomiędzy mocą zbioru par metod odwołujących się do rozłącznych podzbiorów atrybutów a mocą zbioru par metod odwołujących się do przecinających się podzbiorów atrybutów. LCOM =max P Q, 0 P= M i, M j : I Mi I Mj = Q= M i, M j : I Mi I Mj M zbiór metod klasy I Mi atrybuty klasy, do których odwołuje się metoda

Przykład LCOM public class A { private int f1; private int f2; private int f3; private int f4; public void method1() { // I1 = { f1, f2 // uses f1 // uses f2 public void method2() { // I2 = { f2, f3 // uses f2 // uses f3 public void method3() { // I3 = { f3, f4 // uses f3 // uses f4 Para (mi,mj) Ii Ij method1, method2 {_f2 method1, method3 Փ method2, method3 {_f3 LCOM = 1-2 = -1 => 0

Lack of Cohesion of Methods LCOM (wg def. zaproponowanej przez Hendersona-Sellersa w 1996 roku) to względna liczba metod nie odwołujących się do atrybutów klasy LCOM H = m liczba metod, a liczba atrybutów m i liczba metod, które używają i-tego atrybutu LCOM H > 1 to problem a m 1 a i=1 m 1 m i

Wykorzystanie metryk CK do oceny systemu Słaby kod gdy: RFC WMC + CBO duże DIT duże LCOM V.Lang, C.Coleman, NASA

Ocena złożoności systemu Zestaw metryk MOOD (F. Brito e Abreu, 1995) Ocena całego systemu Procentowe miary wykorzystania mechanizmów obiektowości Niezależny od języka, wielkości systemu Zweryfikowany doświadczalnie

Hermetyzacja MOOD MHF Method Hiding Factor AHF Attribute Hiding Factor Dziedziczenie MIF Method Inheritance Factor AIF Attribute Inheritance Factor Polimorfizm PF Polymorphism Factor Powiązania CF Coupling Factor

MOOD: miary hermetyzacji - AHF AHF Attribute Hiding Factor c liczba klas A k liczba atrybutów w k-tej klasie A k j AHF =1 c k=1 c k=1 j k A k j c 1 A k liczba atrybutów k-tej klasy widocznych w j-tej klasie

MOOD: miary hermetyzacji - MHF MHF Method Hiding Factor c liczba klas M k liczba metod w k-tej klasie M k j MHF =1 c k=1 c k =1 j k M k j c 1 M k liczba metod k-tej klasy widocznych w j-tej klasie

Wartości xhf e Abreu przeanalizował AHF i MHF dla 8 dużych projektów o otwartym kodzie AHF zawierał się w przedziale 67% (MFC) 96% (Motif ) MHF zawierał się w przedziale 10% (ET++) 37 % (Motif) Wnioski wydają się dość oczywiste: trzeba ukrywać dane, nie można ukryć wszystkich metod

MOOD: miary dziedziczenia - AIF AIF Attribute Inheritance Factor c AIF= k=1 c k=1 A k i A k c liczba klas A k liczba wszystkich atrybutów w k-tej klasie A k i liczba odziedziczonych atrybutów k-tej klasy

MOOD: miary dziedziczenia - MIF MIF Method Inheritance Factor c MIF = k=1 c k=1 M k i M k c liczba klas M k liczba wszystkich metod w k-tej klasie M k i liczba odziedziczonych metod k-tej klasy

Wartości xif e Abreu przeanalizował AIF i MIF dla 8 dużych projektów o otwartym kodzie AIF zawierał się w przedziale 40% 70% MIF zawierał się w przedziale 64% 85 % Jest to oczekiwane, ale wnioski nie są w tym przypadku tak oczywiste

MOOD: miara polimorfizmu - PF PF Polymorphism Factor PF = k=1 c liczba klas M ko liczba przesłaniających metod w k-tej klasie M k n liczba nowych method k-tej klasy S k liczba podklas k-tej klasy c c k =1 M k o [M k n S k ]

Wartości PF e Abreu przeanalizował PF dla 8 dużych projektów o otwartym kodzie PF zawierał się w przedziale 3% 13% Można przypuszczać, że świadczy to słabym (jeszcze wtedy) wykorzystaniu polimorfizmu Niektóre źródła zalecają > 10%, ale sprawa jest kontrowersyjna

MOOD: miara powiązań - CF CF Coupling Factor CF= c liczba klas C k liczba klas-klientów k-tej klasy S k liczba podklas k-tej klasy c k=1 C k c 2 c 2 k =1 c S k

Wartości CF e Abreu przeanalizował CF dla 8 dużych projektów o otwartym kodzie CF zawierał się w przedziale 5% 20% Wydaje się, że pożądane wartości to przedział 5-15%: zbyt mało: odpowiedzialność jest zbyt skupiona zbyt dużo: system jest mało elastyczny

Przykłady MFC GNU ET++ Motif MHF 24.6% 13.3% 9.6% 39.2% AHF 68.4% 84.1% 69.4% 100.0% MIF 83.2% 63.1% 83.9% 64.3% AIF 59.6% 62.6% 51.8% 50.3% PF 2.7% 3.5% 4.5% 9.8% CF 9.0% 2.8% 7.7% 7.6%

Ocena pakietu Number of Types (NOT) liczba typów (wszystkie klasy, interfejsy,aspekty) Abstractness (A) liczba-abstraktów/liczba-wszystkich-modułów Afferent Couplings (Ca) liczba modułów poza pakietem zależnych od modułów pakietu Efferent Couplings (Ce) liczba modułów w pakiecie zależnych od modułów poza pakietem Instability (I) niestabilność pakietu Ce / (Ce+Ca) Normalized Distance from Main Sequence (Dn) odległość od linii A+I = 1

Ocena kodu: narzędzia http://www.mccabe.com/ http://www.msquaredtechnologies.com/

Ocena kodu: narzędzia http://www.clarkware.com/software/jdepend.html

Ocena kodu: narzędzia RefactorIT

Testowanie Po co testować? Co testować? Kiedy testować? Jak testować? Narzędzia

Po co testować? Testy nie udowadniają poprawności......ale pozwalają wykryć błędy Testy są ważnym narzędziem przyrostowej budowy oprogramowania Testy są niezbędnym narzędziem konserwacji oprogramowania

Co testować? Konstrukcję klasy testy jednostkowe Architekturę systemu testy integracji Wypełnianie wymagań testy systemu Zachowanie systemu testy integracji systemu Nerwy zamawiającego testy akcepujące

Co testować? Źródłó: http://www.methodsandtools.com/archive/archive.php?id=13

Kiedy testować? Jak najwcześniej Projektowanie testów razem z testowanym kodem (a nawet wcześniej) pozwala dopracować funkcjonalność kodu. Wczesne testowanie jest łatwiejsze i szybsze. Jak najczęściej Zwłaszcza przy zmianach w kodzie częste testy są łatwiejsze i skuteczniejsze.

Jak testować? Automatycznie czy ręcznie? Automatycznie = łatwo => często ręczne testowanie może być bardziej wszechtronne, ale bywa zawodne ludzie są leniwi. Zwinnie, czy tradycyjnie? Eksploracyjnie czy skryptowo?

Narzędzia Odpowiednia składnia języka np. metoda main w Javie Biblioteki do testowania jednostkowego xunit: SUnit, JUnit,... JUnitX JTiger TestNG Narzędzia do zarządzania kodem

Biblioteka JUnit Narzędzie do testowania jednostkowego w Javie Stworzona przez K. Becka i E. Gammę jest najbardziej (u zna)danym członkiem rodziny xunit Stosunkowo stara i niewygodna... ale ciągle jeszcze bardzo popularna

JUNIT podstawowe klasy Test <<interface>> TestResults TestCase TestSuite MyTest

JUNIT przykład import java.util.*; public class MathUtl { public double avr( List<Double> l ) { double s= 0; for( double x : l ) s+= l; return s / l.size(); import junit.framework.*; import java.util.*; public class MathUtlTest extends TestCase { public void testaverage2 () { Vector<Double> nums = new Vector<Double>(); nums.add(3.0); nums.add(13.5); asserttrue( MathUtl.avr(nums) == 8.25);

Struktura katalogów ` -- src `-- contact -- BusinessContact.java -- Contact.java -- ExGui.form -- ExGui.java -- PhoneBook.java `-- PhoneBookUtils.java `-- test `-- contact -- BusinessContactTest.java -- ContactTest.java `-- PhoneBookTest.java

JUNIT kompilacja i uruchamianie $ javac -cp /opt/junit/org.junit_3.8.1/junit.jar MUT.java MathUtl.java $ java -cp /opt/junit/org.junit_3.8.1/junit.jar:. junit.textui.testrunner MUT... Time: 0,006 OK (3 tests) $ java -cp /opt/junit/org.junit_3.8.1/junit.jar:. junit.swingui.testrunner MUT

JUNIT struktura klasy testującej konstruktor jest zwykle pomijany metoda setup() służy do inicjalizacji i jest wywoływana przed każdym testem metoda teardown() sprząta i jest wywoływana po każdym teście przypadki testowe są implementowane w postaci metod testcośtam() public class MyTest extends TestCase { void setup() {... void teardown() {... void testone() {...... void testxxx() {...

JUNIT metoda testująca public class JOWTest extends TestCase { private JOW jow = null; public void setup() { jow= new JOW( "Warszawa", 2000000 ); public void testtostring() { String s= jow.tostring(); assertequals( "JOW Warszawa: liczba wyborców: 2000000, głosowało: 0", s ); public void teardown() { jow= null;

Rodzaje assercji asserttrue( [komunikat], warunek ) assertfalse( [komunikat], warunek ) assertnull( [komunikat], referencja ) assertnotnull( [komunikat], referencja ) assertsame( [komunikat], oczekiwana, faktyczna ) assertnotsame( [komunikat], oczekiwana, faktyczna ) assertequals( [komunikat], oczekiwana, faktyczna ) assertequals( [komunikat], oczekiwana, faktyczna,delta ) assertnotequals( [komunikat], oczekiwana, faktyczna ) fail( [komunikat] )

Inicjowanie obiektów Nie w konstruktorze! public class JOWTest extends TestCase { private JOW jow = null; public JOWTest( String testname ) { super( testname ); jow = new JOW( null, 0 );... Obiekt jow nie zostanie utworzony (w wyniku zgłoszenia wyjątku przez konstruktor klasy JOW). Wyjątek zostanie przechwycony przez środowisko Junit, ale komunikat będzie niepełny, a więc mylący.

Inicjowanie obiektów W metodzie setup() public class JOWTest extends TestCase { private JOW jow = null; public setup( ) { jow = new JOW( null, 0 );... Zgłoszenie wyjątku zaowocuje prawidłowym, jasnym komunikatem. java -cp /opt/eclipse/plugins/org.junit_3.8.1/junit.jar:. junit.textui.testrunner JOWTest.E Time: 0,021 There was 1 error: 1) testtostring(jowtest)java.lang.illegalargumentexception: JOW: Zł e wywoł anie konstruktora at JOW.<init>(JOW.java:8) at JOWTest.setUp(JOWTest.java:8) FAILURES!!! Tests run: 1, Failures: 0, Errors: 1

Kolejność wykonywania testów public class JOWTest extends TestCase { testthisbefore() {... To nie zadziała testthisafter() {... - Przypadki testowe są wykonywane w losowej kolejności - Nie mogą mieć efektów ubocznych

Kolejność wykonywania testów public class JOWTest extends TestCase { public JOWTest( String name ) { super( name ); public void testjeszczepozniej() { System.out.println( "JeszczePozniej" ); public void testpotem() { System.out.println( "Potem" ); public void testnajpierw() { System.out.println( "Najpierw" ); public static Test suite() { TestSuite suite = new TestSuite(); suite.addtest( new JOWTest( "testnajpierw" ) ); suite.addtest( new JOWTest( "testpotem" ) ); suite.addtest( new JOWTest( "testjeszczepozniej" ) ); return suite;...

Zewnętrzne zasoby public class MyClassTest extends TestCase {... public void setup() { InputStream data= new FileInputStream( "/var/lib/testdata.txt" );...... Brak danych testowych (np. w innym środowisku) może generować mylące komunikaty.

Wewnętrzne zasoby public class MyClassTest extends TestCase {... private double danetestowe[] = { 1., 3., 5., 7., 13. ; Dane w kodzie testującym public void setup() { InputStream data= this.getclass().getresourceasstream( "mojedanetestowe.dat" );...... Dane pobierane za pośrednictwem class loadera

Testy powinny być niezależne od kontekstu public class MyClassTest extends TestCase {... public void testlocale() { Locale l= Locale.getDefault(); assertequals( "Fri Jun 08 09:07:09 GMT 2007", new Date().toString() );... Nie można oczekiwać określonej daty, czy nawet jej formatu

Testy nie powinny obsługiwać wyjątków public class MyClassTest extends TestCase {... public void testtestnulldata() { try { myclassobject.method( null, null ); catch( NullPointerException e ) { fail( "Przechwycono wyjątek" );... Przechwycenie wyjątku nie pozwala zdiagnozować jego przyczyny

Testowanie wyjątków public class MyClassTest extends TestCase {... public void testtestnulldata() { try { myclassobject.method( null, null ); fail( "Oczekiwano NullPointerException" ); catch( NullPointerException e ) { // jest ok!... Wyjątek powinien być zgłoszony, a więc jego brak jest błędem.

Testowanie wyjątków public class MyClassTest extends TestCase { public void testnulldata() { myclassobject.method( null, null ); public static Test suite() { TestSuite s= new testsuite(); s.addtest( new ExceptionTestCase( "testnulldata", NullPointerException.class ); return s; Specjalna klasa implementująca logikę odwracania wyjątku.

Wady Junit 3.x konieczność dziedziczenia po TestCase sztywne konwencje nazewnicze niewygodne kontrolowanie kolejności testów tylko wspólna inicjacja i finalizacja ograniczona funkcjonalność

Rozszerzenia JUnitX nacisk na testowanie składowych prywatnych JUnit 4.0 wykorzystanie nowych możliwości Javy 5.0 TestNG oddzielna od implementacji konfiguracja testów

JUnitX - Testowanie metod prywatnych (http://www.extreme-java.de/junitx/) public class JOWTest extends PrivateTestCase {... public void testglosuje() throws TestAccessException { jow.glosuje( 100 ); int g= getint( jow, "glosowalo" ); assertequals( 100, g ); public class JOW { private String nazwa; private int liczbawyborcow; private int glosowalo;...

JUnitX uruchamianie testów import junit.framework.*; import junitx.framework.*; public class TestPackage implements junitx.framework.testpackage { static public Test suite () { TestSuite suite = new TestSuite ("JOW tests"); suite.addtestsuite (JOWTest.class); return suite;

JUnitX pośrednik import java.lang.reflect.*; import junit.framework.*; import junitx.framework.*; public class TestProxy extends junitx.framework.testproxy { public Object newinstance (Object[] anarglist) throws TestAccessException { try { return getproxiedclass ().getconstructor ( anarglist).newinstance (anarglist); catch (Exception e) { throw new TestAccessException ( "could not instantiate " + gettestedclassname (), e);...

klasy testowe to POJO wykorzystanie anotacji JUnit 4.0 metody inicjujące/sprzątające związane z konkretnym testem wbudowana obsługa wyjątków sterowanie zbiorem wykonywanych testów obsługa limitów czasowych kompatybilność z JUnit 3.x (dwustronna)

Zastosowanie JUnit 4.x import org.junit.*; import static org.junit.assert.*; public class JOWT4 { private JOW jow = null; @Test public void testtostring() { String s= jow.tostring(); assertequals(... );...... @Before public void makejow() { jow= new JOW(... ); @After public void destroyjow() { jow= null;

Kompilacja i uruchomienie testów $ javac -cp junit4.3.1/junit-4.3.1.jar JOW.java JOWT4.java $ java -cp junit4.3.1/junit-4.3.1.jar:. org.junit.runner.junitcore JOWT4 JUnit version 4.3.1... Time: 0,052 OK (3 tests)

Anotacje Junit 4 @BeforeClass @AfterClass @Ignore @Test(timeout=1000) @Test(expected=MyException)

http://testng.org/ TestNG Testing, the Next Generation klasy testowe to POJO wykorzystanie anotacji metody inicjujące/sprzątające związane z konkretnym testem, grupą, klasą parametryzacja przypadków testowych zależności pomiędzy przypadkami...

http://testng.org/ TestNG Testing, the Next Generation... wbudowana obsługa wyjątków sterowanie zbiorem wykonywanych testów, także przez zewnętrzny plik wykorzystanie programowych asercji Javy obsługa limitów czasowych

Anotacje TestNG @Test wybrane parametry: alwaysrun (nawet, gdy zależy od metody, która padła) dataprovider (skąd dane) dataproviderclass (gdzie szukać dataprovidera) dependsongroups (lista grup) dependsonmethods (lista metod) description enabled expectedexceptions groups timeout

Konfiguracyjne anotacje TestNG @BeforeSuite @AfterSuite @BeforeTest @AfterTest @BeforeGroups @AfterGroups @BeforeClass @AfterClass @BeforeMethod @AfterMethod Parametry: alwaysrun dependsongroups dependsonmethods enabled groups inheritgroups

Inne anotacje TestNG @DataProvider -> Object[][] parametr name @Factory -> Object[] @Parameters parametr value

Przykład @DataProvider(name = "test1") public Object[][] createdata1() { return new Object[][] { { "Cedric", new Integer(36), { "Anne", new Integer(37), ; @Test(dataProvider = "test1") public void verifydata1(string n1, Integer n2) { System.out.println(n1 + " " + n2);

Uruchamianie testów z linii poleceń java org.testng.testng testng1.xml [testng2.xml testng3.xml...] przy pomocy anta przez IDE / pluginy do IDE

Konfiguracja testów public class Test1 { @Test(groups = { "functest", "checkintest" ) public void testmethod1() { @Test(groups = {"functest", "checkintest" ) public void testmethod2() { @Test(groups = { "functest" ) public void testmethod3() { <test name="test1"> <groups> <run> <include name="functest"/> </run> </groups> <classes> <class name="example1.test1"/> </classes> </test>

Konfiguracja testów, cd @Test public class Test1 { @Test(groups = { "windows.checkintest" ) public void testwindowsonly() { @Test(groups = {"linux.checkintest" ) public void testlinuxonly() { @Test(groups = { "windows.functest" ) public void testwindowstoo() { <test name="test1"> <groups> <run> <include name="windows.*"/> </run> </groups> <classes> <class name="example1.test1"/> </classes> </test>

Konfiguracja testów, cd @Parameters({ "first-name" ) @Test public void testsinglestring(string firstname) { System.out.println("Invoked teststring " + firstname); assert "Cedric".equals(firstName); <suite name="my suite"> <parameter name="first-name" value="cedric"/> <test name="simple example"> <--... -->

Ćwiczenie Proszę pobrać niezbędne pliki z http://www.iem.pw.edu.pl/~jstar/studium/junit/ i napisać klasę testową dla JOW z wykorzystaniem Junit3.8, Junit4.3, JUnitX. Przykładowe szkielety do JunitX i Junit4 są dostępne w katalogu podanym wyżej.