Versionshantering Jan Erik Moström
Johan Eliasson Versionssystem Gjorda för att användas av en eller flera personer på en eller flera platser, exempelvis: För en ensam användare som jobbar med ett projekt från flera datorer För att veta att förändringar inte skrivs över av andra då man jobbar flera tillsammans Om man jobbar många tillsammans med samma filer för att veta att dokumenten är senaste versionen. För att gå tillbaka i tiden och se tidigare versioner av dokumenten För att spåra ändringar
Johan Eliasson Programvara GIT CVS SVN (Subversion) Senare programvara. Addresserar några av problemen som fanns i CVS Eclipse i labben har plugin för att jobba med SVN. CVS stöd finns med som standard. Eclipse kan också användas med GIT - EGIT På följande adress finns en guide hur man kan komma igång med SVN i eclipse: http://help.collab.net/index.jsp?topic= /org.tigris.subclipse.doc/topics/toc.html Vill ni använda SVN i projektet så maila support@cs.umu.se att ni vill använda det och ange användarnamn på alla medlemmar i gruppen samt kurskod (5DV133)
SVN Referensmanualen: Version Control with SUBVERSION Ben Collins-Sussman et. al. Version 1.7 finns nu gratis på webben: http://svnbook.red-bean.com/ och i bokform. http://creativecommons.org/licenses/by/2.0/legalcode
Repository Typiskt klient/server-system:
Detta vill man unvika: Problemet med delade filer
Låsning Man kan låsa filer, men...: Restriktiv metod Serialisering av arbetet Om Harry glömmer sitt lås och åker på semester?
Copy-Modify-Merge Den vanligaste modellen: Harry får inte skriva över Sallys fil
Copy-Modify-Merge forts. Konfliktlösning: Merge Kan bli komplicerad om båda ändrat i samma del av filen
Filsystemet Man checkar ut en del av katalogträdet med update Detta ger en lokal arbetskopia Eclipse håller reda på detta
Revisioner Varje ny revision får ett eget nummer Eclipse ordnar det med!
Eclipse
Inställningar i labben Window -> Customize Perspective -> Command Groups Availability Klicka i SVN
Window -> Customize Perspective -> Tool Bar Visibility Klicka i SVN Ev också i Menu Visibility
Arbetsgång Första gången för ett nytt projekt: Dela ut projektet om du skapar projektet Eller skapa från SVN om projektet redan finns För varje editeringssession: Update hämta en arbetskopia att jobba med lokalt Editera filen/filerna Commit spara ändringarna Det kanske inte gick pga att någon annan ändrat filen Gör i så fall Update igen, och lös konflikten Prova Commit igen
Dela ut ett projekt Välj Share Projects... i SVN-menyn
Väl New -> Project... Alltså inte Java Project Skapa projekt från SVN
Projekt från SVN
Välj repository
Välj projekt
Update Gröna pilen uppdaterar kod från servern till lokala maskinen
Commit När du editerat klart, klicka på Commit-knappen (röd pil)
Commit forts. Du kan lägga till en kommentar här
Package Explorer Visar att ditt projekt är uppdaterat och vilken version det har En > framför projektet visar att den lokala kopian har modifierats
Konflikt Någon (Du själv?) har ändrat på en fil från någon annan maskin
Prova med Update Du får se vad som skiler de två versionerna åt
Konflikt
Välj Edit Conflicts Gå till SVN-menyn
Editera konflikterna Editera så att du är nöjd (lokala versionen, till vänster)
Klart Editera
Commit igen Välj Mark as Merged och sedan Commit Serverns version skrivs över
Avancerat Branches Merging Tags
JUnit Johan Eliasson
JUnit Unit testing för java Används för att testa att metoder/klasser beter sig som det var tänkt Många IDE:er tex Eclipse har inbyggt stöd för detta. Arbetsgång: Skapa ett test först det misslyckas Lägg till kod i din klass så att testen klaras Skapa nästa test, lägg till kod osv.
JUnit 3 Vi skriver testklasser och låter dessa ärva från junit.framework.testcase. (JUnit klasserna måste läggas till till projektet då dessa klasser inte är med bland standardklasserna i java) Namnge testmetoderna med test som prefix (det är så de känns igen som testmetoder) Undersök de villkor som ska testas mha de olika assert-metoderna i TestCase Kör testen mha Run -> Run -> JUnit i Eclipse (Se till så att ni ställt in den på att använda version 3)
JUnit 3 forts. Ibland vill man göra grundinställningar som ska göras innan varje test. Dessa kan göras i metoden protected void setup() som körs innan varje test i den klassen Behöver man städa upp efter testen görs detta i metoden protected void teardown() som anropas automatiskt efter varje test.
Villkorskontroller i test Statiska metoder som finns definierade i Klassen Assert (TestCase ärver från denna) asserttrue assertfalse assertnull assertnotnull assertequals Kontrollerar om två värden är lika. För objekt kontrolleras detta mha deras equals-metod. assertsame Kontrollerar om två referenser är lika assertnotsame fail() Misslyckas alltid
Exempel JUnit3 import junit.framework.testcase; public class PolynomTest extends TestCase { } public void testcreateobject() { } double d[] = {1.0, 2.0}; Polynom p = new Polynom(d); assertnotnull(p);
Eclipse 3
Eclipse kom ihåg 4
JUnit 4 Version 4 Vi behöver ej utnyttja arv Testmetoder indikeras mha att vi annoterar dem med @Test Till Test-annotationen kan man även specificera om vi förväntar oss att något särskilt undantag ska kastas @Test(expected=IndexOutOfBoundsException.class) public void outofbounds() { new ArrayList<Object>().get(1); } eller sätta en tidsgräns för testet @Test(timeout=100) (här 100 millisekunder) Använd assert-metoderna för att testa villkoren (samma som i JUnit 3). Ett lätt sätt att använda assert-metoderna (eftersom de nu inte är tillgängliga via arv) är att göra en static import från Assert-klassen
Exempel med JUnit4 import org.junit.test; import static junit.framework.assert.assertnotnull; public class JUnit4TestClass { @Test public void createobject() { double d[] = {1.0,2.0}; Polynom p = new Polynom(d); assertnotnull(p); } }