130 lines
3.6 KiB
Markdown
130 lines
3.6 KiB
Markdown
# Software Craftmanship
|
|
|
|
Här samlas all källkod som tillverkas i kursen Software Craftmanship som går på Högskolan Väst under vären 2015
|
|
|
|
## 1. Intro TDD
|
|
Här skapades den första katan, String Calculator
|
|
|
|
Coding Dojo
|
|
- En plats dit man går för att träna
|
|
- Övning, delibirate practice
|
|
- Smart vs Professional (Readable, Maintainable, Changeable)
|
|
Agilt
|
|
- Sustainable Pace
|
|
- Automatiserade tester mycket viktigt idag
|
|
|
|
TestDriven development by example av Kent Beck
|
|
- http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530
|
|
- Bra på att demonstrera hur TDD går till i praktiken
|
|
|
|
Nytta med TDD
|
|
- More confident, productive, reliable, agile
|
|
|
|
|
|
## 2. Forts + ObjectOrientering
|
|
Här skapade vi den andra katan, BowlingKata
|
|
JUnit test Class Lifecycle
|
|
|
|
Svaret från övningen:
|
|
- static_before
|
|
- Hello
|
|
- before
|
|
- one
|
|
- after
|
|
- Hello
|
|
- before
|
|
- two
|
|
- after
|
|
- static_after
|
|
|
|
En ny test skapas i JUnit som en ny klass med methoden som enda del i denna klass, som anropas. Därför skapas klassen flera gånger.
|
|
|
|
2. Förkortningar på bra tester
|
|
- F ast
|
|
- I ndependant
|
|
- R epeatable
|
|
- S elf validation
|
|
- T imely
|
|
|
|
Eller den här:
|
|
- A utomatic
|
|
- T horough
|
|
- R epeatable
|
|
- I ndependant
|
|
- P rofessional
|
|
|
|
Eller denna variant:
|
|
- R ight (testa rätt sak)
|
|
- B oundries condition (testa gränsfallen)
|
|
- I nverse condition (kan man testa motsatsen av testet)
|
|
- C rosscheck (finns det annat sätt att komma till samma slutsats)
|
|
- E xceptions (hur hanteras dessa)
|
|
- P erformance
|
|
- S et ()
|
|
|
|
Black-Box och White-Box testing
|
|
|
|
Inom WhiteBox-test har man möjligheten att kunna titta in i lådan för att se hur saker fungerar.
|
|
|
|
## 3. Test Double
|
|
Inför detta pas gjorde vi som hemarbete den tredje katan, PokerKata
|
|
Nu skall den göras på riktigt.
|
|
|
|
### Klassdiagram
|
|
|
|
#### Kort
|
|
- Färg
|
|
- Värde
|
|
|
|
#### Kortlek
|
|
- Kort
|
|
- Blanda
|
|
|
|
#### Spelare
|
|
- 5 Kort
|
|
|
|
#### Spel
|
|
- Kortlek
|
|
- Regler
|
|
- Spelare
|
|
- Jämför händer
|
|
|
|
## 4. Intro till Test Doubles
|
|
Kata som gjordes under detta pass var TagManagerKata
|
|
|
|
- Unit-tester prövar en isolerad enhet
|
|
- När en klass dependar på andra (DOC, Dependent on collaborators) behöver vi isolera dem från testerna
|
|
- Test doubles är stand-ins för DOC och gör att vi kan isolera units för att testa ordentligt
|
|
|
|
### Test Doubles
|
|
- Fake.
|
|
- Stub. Mer implementerade än Fake. Även med Stub som är det States som hanteras.
|
|
- Mock. Ramverk används. KAn preparera vissa objekt för att returnera något känt. Medtod-anrop.
|
|
- Spies. Övervakar vad som händer.
|
|
|
|
### Mock
|
|
För workers så körs ofta Classical TDD, medan i Managers så används oftast Mock. Med stubbar kollar man alltid hur States förhåller sig.
|
|
Med mock används i Arrange-delen mock-object som saknar implementation, och i Assert-delen används verify() för att kolla. Vi kollar inte States, utan snarare om anropen har kommit.
|
|
|
|
För att använda mock i Eclipse används Mockito (mockito.org)
|
|
Exempel: Event event = Mockito.mock(Event.class);
|
|
|
|
## 5. Refactoring och Clean Code
|
|
BDD: Behaviour Driven Development. Att utifrån förklarande exempel mellan olika personer och User Stories kunna komma fram till vilket produkt/funktionalitet som skall utvecklas.
|
|
Cucumber school: att få business att prata med utvecklare.
|
|
Bok: Specification by example av Gojko Adzic
|
|
|
|
### Clean Code
|
|
Bra bok om clean code: Kent Beck: Implementation Patterns
|
|
- Vad som anses vara Clean Code beror mycket på den context den befinner sig i.
|
|
- SKapa tydliga datatyper istället för att skicka runt märkliga datatyper
|
|
- Läsbar kod är:
|
|
- - Readable
|
|
- - Changeable
|
|
- gd
|
|
-
|
|
|
|
|
|
|
|
|