Versionshantering. Jan Erik Moström

Transkript

1 Versionshantering Jan Erik Moström

2 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

3 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: /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)

4 SVN Referensmanualen: Version Control with SUBVERSION Ben Collins-Sussman et. al. Version 1.7 finns nu gratis på webben: och i bokform.

5 Repository Typiskt klient/server-system:

6 Detta vill man unvika: Problemet med delade filer

7 Låsning Man kan låsa filer, men...: Restriktiv metod Serialisering av arbetet Om Harry glömmer sitt lås och åker på semester?

8 Copy-Modify-Merge Den vanligaste modellen: Harry får inte skriva över Sallys fil

9 Copy-Modify-Merge forts. Konfliktlösning: Merge Kan bli komplicerad om båda ändrat i samma del av filen

10 Filsystemet Man checkar ut en del av katalogträdet med update Detta ger en lokal arbetskopia Eclipse håller reda på detta

11 Revisioner Varje ny revision får ett eget nummer Eclipse ordnar det med!

12 Eclipse

13 Inställningar i labben Window -> Customize Perspective -> Command Groups Availability Klicka i SVN

14 Window -> Customize Perspective -> Tool Bar Visibility Klicka i SVN Ev också i Menu Visibility

15 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

16 Dela ut ett projekt Välj Share Projects... i SVN-menyn

17 Väl New -> Project... Alltså inte Java Project Skapa projekt från SVN

18 Projekt från SVN

19 Välj repository

20 Välj projekt

21 Update Gröna pilen uppdaterar kod från servern till lokala maskinen

22 Commit När du editerat klart, klicka på Commit-knappen (röd pil)

23 Commit forts. Du kan lägga till en kommentar här

24 Package Explorer Visar att ditt projekt är uppdaterat och vilken version det har En > framför projektet visar att den lokala kopian har modifierats

25 Konflikt Någon (Du själv?) har ändrat på en fil från någon annan maskin

26 Prova med Update Du får se vad som skiler de två versionerna åt

27 Konflikt

28 Välj Edit Conflicts Gå till SVN-menyn

29 Editera konflikterna Editera så att du är nöjd (lokala versionen, till vänster)

30 Klart Editera

31 Commit igen Välj Mark as Merged och sedan Commit Serverns version skrivs över

32 Avancerat Branches Merging Tags

33 JUnit Johan Eliasson

34 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.

35 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)

36 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.

37 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

38 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);

39 Eclipse 3

40 Eclipse kom ihåg 4

41 JUnit 4 Version 4 Vi behöver ej utnyttja arv Testmetoder indikeras mha att vi annoterar dem Till Test-annotationen kan man även specificera om vi förväntar oss att något särskilt undantag ska public void outofbounds() { new ArrayList<Object>().get(1); } eller sätta en tidsgräns för (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

42 Exempel med JUnit4 import org.junit.test; import static junit.framework.assert.assertnotnull; public class JUnit4TestClass public void createobject() { double d[] = {1.0,2.0}; Polynom p = new Polynom(d); assertnotnull(p); } }