Tavaliselt ei meeldi programmeerijatele dokumentatsiooni kirjutada. Parema meelega kirjutaks ikka koodi. Tore oleks, kui ärireeglid asuks kõik ühes kohas. Kui see nii ei ole erinevatel põhjustel, siis segaduse vähendamiseks oleks hea, kui me leiame need vajadusel ruttu üles ühest kohast, kuigi need asuvad eri kohtades laiali. Mis siis, kui midagi asub meil teenusepakkuja veebiserveris, midagi Java-s kirjutatud rakenduses, midagi andmebaasi stored procedure-s, midagi C#-s kirjutatud rakenduses, midagi Accessi VBA rakenduses jne..? Ma arvan, et enamasti nii ongi ja sellega tuleb elada.
Pakun välja ühe variandi, kuidas veidi rohkem asju korras hoida. Laadi alla DbFit ja hakka kirjutama nii dokumentatsiooni kui ka testitavat koodi. Sellest moodustub nii wiki dokumentatsiooniga kui ka testide jooksutamise keskkond. Võimalikult palju väljenda ennast koodi ja testidega nagu programmeerijale omane. Kui tavalises keeles kirjutamine tundub tõhusam, siis tee seda wiki lehtedel.
Kui on vaja infot otsida, siis saab seda kergesti FitNesse sisse ehitatud otsingutööriistaga. Näiteks, kui mingi asi vajab lõpetamist, kirjuta wikisse tekst "TODO:". Kui nüüd seda fraasi otsid, leiad üles kõik lõpetamata asjad. Otsingu võid ka salvestada näiteks pealehele:
Lõpetamata asjad: [[Otsi TODO: tegemata asju][pealeht?responder=search&searchString=TODO%3A&searchType=Search+Content]]
Kui töö käigus selgub, et teste või dokumentatsiooni pole piisavalt, ära tee asja hullemaks, vaid paremaks. Kirjuta wikisse selgitus või veel parem: kirjuta juurde mõni test. Nii tehes järgid The Boy Scout Rule reeglit.
Panen siia näite, kuidas testida MySQL funktsioone. Lihtsuse mõttes ei kirjuta ma enda funktsiooni, vaid testin olemasolevat SUBSTRING funktsiooni.
Panen kausta C:\dbfit-complete-3.2.0 faili connection.conf järgmise sisuga:
# DBFit connection properties file connection-string=jdbc:mysql://host:port/db?user=dbuser&password=dbpassword
Lähen aadressile http://localhost:8085/DbFunctionTest ja panen sinna teksti:
!path lib/*.jar !|dbfit.MySqlTest| !|ConnectUsingFile|connection.conf| !|Query| SELECT SUBSTRING('ABCDEFG', 1, 1) AS result| |result| |A| !|Query| SELECT SUBSTRING('ABCDEFG', 2, 1) AS result| |result| |B|
Tulemus:
Mis aga siis, kui funktsiooni SUBSTRING asemel on mul enda kirjutatud funktsioon, mis sisaldab endas tähtsat äriloogikat? Sellisel juhul on mul ühekorraga see funktsioon nii dokumenteeritud kui ka testitud. Siinkohal on oluline märkida, et seda wiki lehte saab näidata ka reeglistiku kehtestajale või vastutajale, kes tavaliselt ei ole programmeerija. See on suure tõenäosusega arusaadav ka talle.
Näiteks, kui kirjeldan wiki dokumendis üldist loogikat, soovin ehk tutvustada kasutusel olevat MySQL tabelit. Selleks ei ole mul vaja muud teha, kui lisada dokumenti üks rida ja näengi juba selle struktuuri ning esimest 10 rida:
!|Inspect Query|select * from minu_tabel LIMIT 10|
Väikese artikli, kuidas testida C# koodi, leiad siit.
Linke:
https://en.wikipedia.org/wiki/Wiki
http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule