Lektion 13 Övningar TDD Bryt ut logiken för att göra Bulk-ersättning av Category i Index i ProductControllern. Målet är inte att du skall komma fram till exakt samma lösning som jag kom fram till. Målet är att du bryter ut logiken till en Domain-klass mha TDD och att du övertygar dig själv om att din lösning är testbar, smidig att använda och lätt att underhålla (dvs. testbar, liten och med informativa namn/variabler med utbrutna metoder om lösningen blir stor). Stöd: Börja skissa på hur du vill använda klassen/metoden du tänker skapa. Tänk inte på namn, etc. ännu. Sikta på att skapa ett skelett för det du vill skapa utan implementation, vi kommer låta testerna driva implementationen. Behåll implementationen i test-klassen tills du är helt färdig med implementation och tester. Skriv ett första naivt test se till att det failar. Jobba enligt Red -> Green -> Refactor för att iterera fram test och implementation parallellt. Varje nytt test bör få failed innan du börjar skriva implementation. När du skrivit minimalt med test för att få ditt första test att passera gå vidare till att skriva nästa test. När du känner att du skrivit tillräckligt med tester refaktorera implementationen tills du är nöjd med stöd av nuvarande tester. När du är nöjd med både implementation och tester rätta ev. till namn på tester, testklass och implementationer flytta implementationen till rätt ställe och fixa till namespaces i implementation och test. Kontrollera att alla test passerar efter allt är på sitt rätta ställe. Använd implementationen där den var tänkt att använda. Delarna i denna solution bygger på sådant vi gått igenom under tidigare lektioner. Vi använder EF Code First för att skapa en databas och Ninject för att bygga en ControllerFactory allt annat är byggt från scratch.
För att skapa detta projekt har jag: 1. Skapat en tom solution Lektion13 2. Lagt till ett MVC 3 projekt Lektion13.Web 3. Lagt till ett Test-projekt Lektion13.Tests 4. Lagt till ett Class Library Lektion13.Domain 5. Lagt till Entity Framework i Lektion13.Domain med NuGet. 6. Lagt till Entity Framework, Ninject i Lektion13.Domain med NuGet 7. Lagt till Moq i Lektion13.Tests med NuGet. 8. Lagt till referens till Lektion13.Domain i Lektion13.Web 9. Lagt till referens till Lektion13.Web, Lektion13.Domain i Lektion13.Test 10. För att fixa namespace på nedanstående har jag använt Search and replace in entire solution LektionXX -> Lektion13 efter att samtliga filer är tillagda (Edit -> Find And Replace -> Quick Replace). 11. Lagt till klasser för Domain.Entities + Domain.Entities.Abstract (Tagit existing items från tidigare lektion och fixat till namespace på dem). 12. Lagt till klasser för Domain.Repositories + Domain. Repositories.Abstract (Tagit existing items från tidigare lektion och fixat till namespace på dem). 13. Lagt till klasser för Domain.Contexts + Domain. DBInitializers (Tagit existing items från tidigare lektion och fixat till namespace på dem). 14. Lagt till NinjectControllerFactory i Web.Infrastructure och Lagt till Bindings för IProductRepository och Repository<> (Tagit existing items från tidigare lektion och fixat namespace) 15. Satt ControllerFactory i Global.asax/Application_Start till NinjectControllerFactory (Som vi plockade in I steg 14). 16. Satt Database initialize I Global.asax/Application_Start till EFDBInitializer (Den vi tog in I steg 13 ovan). 17. Lagt till en ny, tom, ProductController lagt till en ny, tom, vy för Index i denna. Jag har lagt till en private member för IProductRepository och skapat en ny konstruktor. 18. Lagt till en sektion för EF Code First i Web.config direkt under Lektion13.Web. 19. Lagt till en ActionLink till Product/Index i _Layout.cshtml. 20. (Nytt) Jag har lagt till en ObjectMother-klass i Testprojektet Helpers/ Ovanstående tog ~5-10 min, men det bygger ju på att vi redan innan har gjort en hel del. Git Repetition och Fördjupning Ni kommer skapa ett nytt repository för dessa övningar antingen klonar ni ett nytt repository från github eller så skapar ni ett nytt lokalt repository med git init. Git repetition och fördjupning för ensam utvecklare i lokalt repo Innan vi kör igång skaffa dig ett humm om vad skillnaden mellan Working Copy, Staging Area och Local Repository är. Följande övningar är tänkta att göras med git på kommandoraden (t.ex. kan du via github for windows välja open shell here ). Efter övningarna kommer du säkert inse att vissa github for
windows-kommandon är en sammanslagning av fler git-kommandon och att det finns saker du inte kan göra med det grafiska gränssnittet. Vi kommer jobba med textfiler i de här övningarna men principerna är exakt de samma om vi skull jobba med.cs-filer eller någon annan filtyp som inte är binär. Instruktionerna för dessa övningar är mycket mer knapphänta än vad de varit tidigare ifall du får ett resultat du inte förväntar dig, eller inte hänger med på vad ngt kommando gör fråga mig, dina klasskamrater eller sök på nätet. Jag har inte planerat att lägga ut svar på dessa övningar. Kommandon för att lägga till filer, ändra i filer, ta bort eller ändra namn på filer, etc. är inte gitkommandon dessa löser du med verktygen i kommandoprompten eller powershell. Kommandon i powershell känns igen från UNIX-världen (powershell är f.ö. bara att tanka hem till windows och är ett väldigt kraftfullt shell där du bl.a. har tillgång till hela.net-biblioteket, etc) som exempel (generellt sett är dessa kommandon alias för att göra det enkelt att komma från UNIX till powershell): touch README.txt skapar en fil, README.txt echo test >> README.txt lägger till raden test i README.txt (README.txt skapas om den inte finns) cat README.txt listar innehållet I README.txt Obs! touch + echo kommer skapa filer med UTF-16 encoding, vilket git inte känner igen som text-filer per default (git kommer tro att det är binär-filer) detta kommer påverka vad vi se när vi kör git diff, varför jag använder notepad när jag jobbar med textfiler i nedanstående exempel. ( notepad ny_fil.txt och notepad befintlig_fil.txt fungerar i powershell du kan naturligtvis använda en annan editor om du föredrar det). 1. Skapa ett nytt repo på lämpligt ställe med git init 2. Skriv git status vad får du för resultat? 3. Lägg till en ny textfil README.txt (Obs! se till att detta är en fil som git känner igen som en textfil se ovan). 4. Skriv git status vad får du för resultat? 5. Skriv git add README.txt skriv sedan git status vad får du för resultat? 6. Skriv git commit skriv sedan git status Vad får du för resultat? 7. Skriv git log resultat? (Hur hittar du SHA-hashen för de senaste commit?) 8. Skriv git show HEAD resultat? 9. Skriv git show [SHA] där [SHA] är de 6 första tecknen från din commits SHA-hash resultat? 10. Lägg till en textrad i README.txt skriv sedan git status resultat? 11. Skriv git add u, sedan git status resultat? 12. Lägg till ytterligare en fil, file.txt 13. Skriv git commit m Ändrat README sedan git status - resultat? 14. Skriv git add. sedan git status resultat?
Nu bör du ha hyfsad koll på Working Copy, Staging Area och Local Repository. Du bör även ha koll på hur man kan använda SHA-hashar och hur vi kan titta på nuvarande läge i ditt repo samt historik för repot. Härnäst ska vi titta på hur vi kan åskådliggöra skillnader mellan olika commits och skillnader i individuella filer i olika commits (OBS! tänk på att ifall du använt echo/touch tidigare så kommer git hantera filen som en binär-fil och är därmed inte lika bra på att visualisera skillnader mellan olika filversioner. Dvs. du bör använda notepad eller motsv. för att skapa samt ändra filer för dessa övningar). 15. Ersätt textraden i uppg. 9. med en annan textrad. Commita ändringarna 16. Skriv git log (vad gör git log? Testa även git shortlog och git log --oneline) 17. Skriv git diff HEAD~1..HEAD resultat? 18. Skriv git diff HEAD~1.. resultat? (Är det skillnad på HEAD~1.. och HEAD~1..HEAD?) 19. Vad gör git diff HEAD~2..? 20. Vad gör git diff HEAD~2..HEAD~1? 21. Kan du uttrycka git diff HEAD~2..HEAD~1 på något annat sätt? (tips: SHA-hashar) 22. Hur gör du om du endast vill titta på diff för en individuell fil? (tips: testa lägg till filnamn på slutet av ett git diff-kommando). Nu bör du ha en uppfattning om lite olika sätt att se skillnader mellan olika commits och skillnader mellan innehållet i en individuell fil mellan olika commits. Nu skall vi titta på hur vi kan återställa individuella filer eller hela commits. 23. Lägg till ytterligare en textrad i filen README.txt 24. Kör git add u 25. Kör git status 26. Kör git reset README.txt kör sedan git status resultat? 27. Skriv git checkout README.txt kör sedan git status resultat? Vilken version av README.txt har du nu? 28. Skriv git checkout [SHA] README.txt, där [SHA] är SHA-hashen där README.txt lades till. 29. Hur ser din README.txt ut nu? 30. Commita den nuvarande README.txt till Local Repository 31. Skapa ny fil och commita 32. Kör delete på den nya filen (med rm fil eller motsv) 33. Kör git status (resultat?) Kör git add. (resultat?) Kör git add A (resultat? Vi hade kunnat köra git rm här med) 34. Skapa två nya filer, kör add på dessa filer. Kör git status. Skriv sedan git reset hard (skall vara två st. framför hard). Kör git status resultat? (Detta kan vara en sista utväg ur en snårig situation lägg märke till att vi hade kunnat köra Lägg märke till att checkout/reset kan köras både på individuella filer och hela commits. Avslutningsvis skall vi kolla på.gitignore-filen 35. Skapa en ny katalog Temp/ skapa några nya filer i temp-katalogen.
36. Skapa en fil test.tmp i rooten för ditt repository (filen är tänkt att representera någon form av skräp-fil) 37. Kör git status (du bör inte kört add på någon fil) 38. Skapa en.gitignore-fil. Lägg till en rad för Temp / temp beroende på vad du döpte din katalog till (eller [Tt]emp för att fånga båda. Lägg till *.tmp på nästa rad. 39. Kör git status resultat? Git repetition utveckling mot remote repo För att experimentera mot en remote-repo så kan du klonat från github, skapa ytterligare en lokal klon (git clone [github adress])av ditt github repo lägga till någon ny fil och pusha upp det till }github. Återgå sedan till din första klon. Alternativt kan du simulera ett remote repository enligt följande: skapa ett lokalt repository med git init. Gå in i detta repo och skriv git config - -bool config.bare true. Skapa sedan en klon av detta repo med t.ex. git clone. [path till klon1] och sedan en annan klon med tex. git clone. [path till klon2] peka inte på en path inne i ditt första repo när du anger path till dina kloner. 40. Skapa en fil i Klon 1, add, commit och kör git push origin master. 41. Gå till Klon två och skriv git fetch origin skriv git status resultat? 42. Kör git merge origin resultat? 43. Skapa en fil i klon 2, add, commit och kör git push origin master. 44. Gå till klon 1 och skriv git pull origin skriv git status resultat? 45. Vad är skillnaden mellan git pull och git fetch? Att använda git för utveckling i grupp När man utvecklar i grupp blir det plötsligt väldigt viktigt att kunna hantera branches, merges och konflikter vid merges. Detta är naturligtvis väldigt bra att kunna även om man är en ensam utvecklare i ett repository men när man utvecklar i grupp är det svårt/omöjligt att undvika dessa kommandon och koncept. 46. Skapa en konflikt genom att lägga till en rad i en textfil i klon2 add, commit, push. Lägg därefter till en annan rad i klon3 (på samma rad som i klon2 innan du kört pull i klon3) add, commit, pull 47. Lös komflikten med t.ex. notepad add, commit, push. 48. Skapa en branch från ett visst SHA git checkout SHA b NewBranchName (Lägg märke till att du hade kunnat skapa en branch från t.ex. en tag eller HEAD). 49. Mergea in master i din nya branch med git merge master 50. Skapa en ny fil i branschen add, commit 51. Merga in din branch i master igen git merge NewBranchName från master 52. Commita din merge, kör git push origin. (konflikter vid merges hanteras precis som konflikter vid pull det är i själva verket samma sak). 53. Skapa en ny branch med git branch AnotherBranch 54. Växla över till den nya branschen med git checkout AnotherBranch 55. Lägg till en fil i din nya branch, add, commit 56. Växla över till master branschen igen med git checkout master. Hur växlar du över till branschen du skapade i uppgift 50?
57. (Om du vill): Installera ett externt tool för att hantera konflikter vid merges (t.ex. p4merge eller kdiff3). Jag använder p4merge och har lagt tillföljande i [min Users hem-mapp]\.giconfig: [diff] tool = p4merge [difftool "p4merge"] [merge] cmd = "p4merge.exe $LOCAL $REMOTE" tool = p4merge [mergetool "p4merge"] cmd = "p4merge.exe $BASE $LOCAL $REMOTE $MERGED" trustexitcode = true keepbackup = true Avslutningsvis Ifall github for windows eller git flippar ur så beror det förmodligen på config-inställningar. Dessa hittar du i.gitconfig i din användares hem-mapp. Jämför med någon klasskamrats.gitconfig eller sök på nätet (glöm inte göra backup ifall du börjar ändra i denna fil). För att kunna jobba med git i grupp på ett vettigt sätt så behöver du kunna en del koncept och kommandon du behöver inte kunna allt för att komma igång men du bör sikta på att ha koll på följande så snart som möjligt: Working Copy vs. Staging Area vs. Local Repository vs Remote Repository. Vad en git SHA är och hur den kan användas. Vad.gitignore är och hur den används. git add (., u, A, [file]), git commit ( -m, -am ), git status, git log ( oneline, graph ), git show (testa också t.ex. git graph all oneline) git diff (SHA1.. SHA2, HEAD~1..HEAD, HEAD~1..), git checkout ([file], HEAD, [SHA], [tag], -b [branchname], -b [ny branch]), git reset ( - -hard, - -soft, - -hard HEAD~1, - -hard [SHA], - -soft HEAD~1, - -soft [SHA] ), git branch (-m), git tag git fetch, git pull, git push ([remote], - -tags ) Överkurs:
(git reflog + checkout, git rebase, git cherry-pick, git stash (list, apply, pop, drop, branch)) Om du söker info om hur man använder git rebase håll dig till officiella eller trovärdiga källor, det är ett kommando som kan missbrukas spontant tror jag inte nödvändigtvis ni behöver kommandot i projektet.