Diskusiju o Test Driven Development - TDD u daljem tekstu (Programiranje upravljano testiranjem) pocecemo sa izvanrednim postom Stephen Walther-a koji u potpunosti prevodim sa njegovog bloga. U tom postu Stephen diskutuje teorijske osnove TDD-a. Orginalan tekst moze da se nadje na slijedecoj adresi:
http://weblogs.asp.net/stephenwalther/archive/2008/09/05/asp-net-mvc-application-building-forums-1-create-the-perfect-application.aspx
Kreirajmo perfektnu aplikaciju
Sta su odlike dobrog software-a ?
Ja ne zelim da kreiram bilo koju aplikaciju. Cilj je da kreiram najbolju mogucu aplikaciju. Moj skromni cilj je da kreiram perfektnu aplikaciju.
Taj cilj me neizbjezno navodi slijedecem pitanju: Sta je to dobar software? Sta je to sto cini jednu aplikaciju boljom ili losijom od druge? Na kraju krajeva ne mogu trvrditi da sam kreirao perfektnu aplikaciju bez definicije dobrog software-a.
Moja definicija dobrog software-a je:
Dobar software je software koji je dizajniran da lako opstane promijene software-a
Postoji vise razloga da se izmjeni software (pogledaj Feathers stranica 3):
1.) Dodavanje nove funkcije software-u
2.) Otklanjanje bug-ova u software-u
3.) Optimiziranje software-a
4.) Unaprijedjenje dizajna software-a
Lose dizajniran software je tesko izmjeniti. Software moze da bude tako lose dizajniran da se svako boji da radi na njemu. Svi smo vidjeli takav software. Kad je software lose programiran, sve sto zelis je da nestane, ili cak sto je gore da ga ponovo programiras od pocetka.
Izbjegavati "Kod Smrad" (Code Smell)
Robert i Micah Martin opisuju naznake loseg software-a kao kod smrad. Slijedece naznake lose programiranog software-a mogu se opisati kao kod smrad:
1.) Krutost - Krut software zahtijeva lanac promijena kada se izmjeni u jednom mjestu
2.) Krhkost - Slama se na vise mjesta kada se napravi jedna promijena
3.) Nepotrebna kompliciranost - komplikovan software je tesko promijeniti
4.) Nepotrebno dupliciranje - sadrzi duplicirani kode
5.) Neprovidnost - tesko ga je razumijeti
( Micah and Robert Martin opisuju kod smrad u njihovoj knizi Agile Principles, Patterns, and Practices in C# na strani 104. Autor preporucuje knjigu.)
Sve naznake kod smrada su vezan za promijenu, sve su prepreka promijeni software-a.
Principi Software Dizajn-a
Slijedjenje principa software dizajna poizvodi software koji je lako promijeniti. Postoji nekoliko lista principa software dizajn-a, koje se preklapaju u sadrzaju.
Na primjer, the Cunningham and Cunningham Wiki opisuje 11 principa Objektima Orijentisanog Dizajna:
http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
Prvih 5 principa odgovaraju principima software dizajna-a Robert Martin-a (i njegovog sina Micah Martin-a) promoviranih u knjizi Agile Principles, Patterns, and Practices in C#. Robert Martin takodjer diskutuje ove principe u Object Mentor blog-u:
http://www.objectmentor.com/resources/publishedArticles.html
Pronasao sam i dodatne knjige koje sadrze informacije o principima software dizajn-a: Head First Design Patterns od Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates i Head First Object-Oriented Analysis and Design od Brett McLaughlin, Gary Pollice, i David West. Principi izneseni u ovim knjigama nisu isti kao Robert Martin-ovi principi ali su vrlo blizu Martin-ovim.
Prava istina je da svi ovi principi imaju porijeklo u radovima Robert-a Martin-a. Robert Martin nije izmislio ove principe, ali je prvi koji ih je sastavio u jednoj listi:
· SRP – Single Responsibility Principle (Princip jedne odgovornosti)
· OCP – Open Closed Principle (Otvori zatvori princip)
· LSP – Liskov Substitution Principle (Liskov princip zamjene)
· ISP – Interface Segregation Principle (Princip odvajanja interface-a)
· DIP – Dependency Inversion Principle (Princip inverzije ovisnosti)
Ova je kolekcija poznata pod akronimom SOLID ( da to je akronim akronima).
Slijedi lista software dizajn principa iz knjige Head First Design Patterns :
· Encapsulate what varies
(Obuhvati u cjelinu sto se mijenja)
· Favor composition over inheritance
(Daj prednosti kompoziji ispred naslijedjivanja)
· Program to interfaces and not implementations
(Programiraj prema interfejsima (interface) a ne prema razradi (implementations))
· Strive for loosely coupled designs between objects that interact
( Tezi labavim vezama izmedju objekata koji komuniciraju)
· Classes should be open for extension but closed for modification
(Klase trebaju da budu otvorene prosirivanju a zatvorene za promijene)
· Depend on abstractions. Do not depend on concrete classes
(Zavisnost treba da bude o apstrakcijama a ne konkretnim klasama)
· Only talk to your friends
(Pricaj samo sa prijateljima)
· Don’t call me, we’ll call you
( Ne zovi me, zvacu te)
· A class should have only one reason to change
( Klasa bi trebala da ima samo jedan razlog za promijenu)
Ponovo postoji dosta preklapanja u listi principa sa prethodnom listom. Na primjer "princip jedne odgovornosti" je isti princip kao sto je da "klasa bi trebala da ima samo jedan razlog za promijenu". Naglasak na principima je razlicit. Preporucujem istrazivanje oba izvora.
Svrha svih ovih principa je programiranje software-a koji moze da prezivi promijene. Ovi principi naglasavaju osnove kreiranja software-a koji ce da opstane dugo vremena.
Software design patterns (Obrazci dizajniranja software-a)
Software Design Patterns predstavljaju strategiju za primjenu Software dizajn principa. Drugim rijecima, Software dizajn principi su dobra ideja, a Software Design Patterns (Obrazci dizajniranja software-a) je alat potreban za implementaciju ideje (nesto kao cekic).
Koncept Software Desing Pattern-a je prvi put promovirana u knjizi Design Patterns: Elements of Reusable Object-Oriented Software (Knjiga je poznata kao "The Gang of Four" - knjiga Groupe Cetvorice). Isnpirisala je mnoge knjige o Software Design Patterns.
The Head First Design Pattern knjiga sadrzi jednostavniju introdukciju u Software Design Patterns nego Gang of Four knjiga. The Head First Design posjeduje poglavlja o 14 Software Design Patterns (Obrazaca dizjniranja software-a):
· Strategy
· Observer
· Decorator
· Factory
· Singleton
· Command
· Adaptor
· Façade
· Template
· Iterator
· Composite
· State
· Proxy
· Compound
Slijedeca knjiga priznata u podrucju Software Design Patterns je Enterprise Application Architecture. Knjiga ima pripadajuci web sajt koji nabraja Software design patterns:
http://www.martinfowler.com/eaaCatalog/
Software Design Patterns daju obrazce po kojima se moze pisati kod koji se moze lako izmjeniti. Na primjer kada budemo pisali forum aplikaciju (autorov demo projekat) koristiti cemo Software Design Pattern poznat kao Repository Pattern. Eric Evans, u knjizi Domain-Driven Design, opisuje Repository pattern :
Repository predstavlja sve objekte odredjenog tipa kao konceptualnu cjelinu (obicno simuliranu). Ponasa se kao kolekcija, sa izuzetkom mogucnosti detaljnijeg upita (Querying). Objekti odgovorajacueg tipa su dodati i brisani, i podrzavajuca logika Repostory-ja dodaje ili brise objekte iz baze podataka (str 151.).
Prema Evans-u, jedna od najvecih prednosti Repository obrazca je "odvajanje dizajna aplikacije i domene od persistence (spremiste) tehnologije,strategije visestrukih baza podataka , ili cak visestrukih spremista podataka. Drugim rijecima, Repository obrazac omogucava zastitu aplikacije od promijene kod-a pristupa bazama podataka.
Upotrijebicemo Repository obrazac (pattern) da izoliramo nasu aplikaciju od narocite tehnologije perzistiranja podataka. Aplikacija ce biti dizajniranja na takav nacin da lako mozemo promijeniti tehnologiju spremista podataka kao sto su LINQ to SQL, Entity Framework, ili cak nHibernate.
Test-Driven Development
Kreiracu moju MVC aplikaciju upotrebom test driven developmen (TDD - programiranje upravljano testiranjem). Prije nego sto napisem i jednu liniju kod-a aplikacije , kreiracu unit test za kod aplikacije.
TDD je bolji pristup iz slijedecih razloga:
(1) Kreiranje testova za aplikaciju stvara strukturu za bezbjednu izmjenu kod-a
(2) Kreiranje testova primorava programera da pogramira loosely coupled (labavo povezan) kod
(3) Kreiranje testova prije kod-a aplikacije primorava programera da gleda na aplikaciju ocima korisnika
Razmotrimo sada svako od ovih prednosti.
Prvo unit testing omogucava laku izmjenu kod-a. Ovu tacku Michael Feathers naglasava u njegovoj knjizi Working Effectively with Legacy Code. U knjizi on definise legacy (zastarjeli) kod kao kod bez testiranja (poglavlje xvi).
Kad imate aplikaciju pokrivenu unit test-ovima, mozete izmjeniti aplikaciju bez straha da ce izmjena dovesti do prestanka rada aplikacije. Unit tests cini refactoring (reorganizovanje) aplikacije bezbjednim. Ako mozete refactor (reorganizovanje) kod-a upotrebom Software Design Patterns to ce da rezultira kod-om koji se lako mijenja.
Drugo praktciranje TDD primorava pisanje kod-a na narocit nacin. Kod stvoren na ovaj nacin je obicno loosley coupled kod (labavo povezan). Unit test ce da testira malu cjelinu kod-a (unit) u izolaciji. Za gradnju aplikacije koja moze da se testira, mora se stvarati n nacin koji kreira izolirane komponente.
Jedna klasa (class) je labavo povezana za drugu klasu (class) kada mozete izmjeniti jednu klasu bez potrebe da izmjenite drugu klasu. TDD primorava kreiranje veoma labavo povezanog koda. Labavo vezani kod je lako izmjeniti.
Konacno TDD primorava posmatranje software-a ocima korisnika. Pisanjem test kod-a prije aplikacijskog gleda se na aplikaciju iz perspektive programera koji ce koristiti aplikaciju u buducnosti ( cak mozda i programera koji je kreirao aplikaciju). Posto TDD primorava pisanje aplikacije razmatranjem kako ce buduci programer da ga koristi, kod je obicno bolje dizajniran upotrebom TDD-a.
Mongo truda danas, puno koristi sutra
Kreiranje software-a TDD-om zhtijeva mnogo napora prije pisanja kod-a aplikacije. Programiranje testova uzima vremena. Ideja je da kreiranje testova danas rezultira ogromnim prednostima u buducnosti.
Postoje dva nacina da postanete programer, Jedan je cowboy a drugi je strucnjak (craftsman). Cowboy odmah uskace i pise kod. Cowboy moze kreirati aplikaciju veoma brzo. Problem sa cowboy-ima je da neko mora da odrzava tu aplikaciju u buducnosti.
Strucnjak je strpljiv. Strucnjak gradi aplikaciju pazljivo na nacin umjetnik i zanatlija rade svojim rukama. Strucnjak ce da pokrije citav aplikacijski kod unit test-ovima. Strucnjaku treba vise vremena da kreira aplikaciju. Ali kada je aplikacija gotova, mnogo je lakse uklanjanje bug-ova i dodavanje novih funkcija aplikaciji.
Zakljucak
Cilj je kreiranje MVC aplikacije koja ce da opstane dugo vremena. Aplikacija nije stvorena da radi samo danas, nego da zadovolji kriterija koja ce da evoluriaju i postavljaju nove zahtijeve u buducnosti.
Koristicemo Microsoft ASP.NET MVC framework da kreiramo aplikaciju. Framework omogucava lako pisanje test kod-a, jer je dizajniran od pocetka da podrzava TDD.