Ohjelmistotuotantoprojekti Kasi PÖYTÄKIRJA 14.03.2007 AIKA 14.03.2007 10.15 PAIKKA Sali A319 Tietojenkäsittelytieteen laitos (Exactum) Gustaf Hällströmin katu 2b, Helsinki OSALLISTUJAT Palomäki Tuukka, Puheenjohtaja Holmas Lauri Lahtinen Joni Penttilä Markus, Sihteeri Sarin Antti-Pekka Tikkala Ilkka Saaristo Jaakko, Ohjaaja, saapui 10.22 POISSA Kestilä Veli-Pekka ASIALISTA 1. Kokouksen avaus Puheenjohtaja avasi kokouksen klo 10.17. 2. "Missä mennään" ja mitä on saatu aikaan katsaus Tietokantakomponentti: n. puolet koodista valmiina, tietokannan hakulauseet valmiina GUI: lisää tehty, ei vielä valmis, kommentteja kirjoitettu Raportointiliittymä: ei muutosta maanantaisesta Authentication: jokseenkin valmis Authenticationin poikkeuksien käsittely jätetään toiseen sykliin. 3. Nakkilista: - db-komponentin tila: Palomäki tarkastaa kyselyt, Lauri hoitaa ohjelmoinnin loppuun ennen perjantaita. - GUI Lahtinen ja Penttilä hoitavat loppuun. - omatestaus Holmas totesi, että itsetestaamisesta tulee karvaiset kämmenet. - raportointiliittymän basic auth Palomäki selvittää miten tapahtuu ja jatkaa raporttiliittymän viilausta muutenkin. Testauksesta on puhuttu kohdassa neljä. Kestilä yksikkötestaa FingerprintAuthenticationin ja Authenticationin, mikäli tilanne sallii. 4. Muut asiat Alustavasti päätettiin työskennellä myös "pääsiäisloman" (5.-11.4.) aikana. --------------------------------------------------------------------------------------- Ohjaajan kommentteja projektista: Projektin tuotokset palautetaan kahdella identtisellä cd:llä, cd:n rakenne kannattaa suunnitella hyvin. Dokumentaatiota ei tarvitse printata, ellei asiakas erikseen vaadi. Ohjelma asennettaneen asiakkaan käytettäväksi projektin puolesta. Suunnitellaan ohjelmakoodien ja dokumenttien yms. materiaalien sijoittelu cd:lle huolellisesti. Jostakin selkeästä paikasta pitää löytyä luettelo (ylläpitodokumentti, readme-tiedosto) kaikesta tuotetusta materiaalista. Luokka-API:ssa (suunnitteludokumentissa) parametrien ja paluuarvojen sallitut arvot ja poikkeuskäsittely on kirjattu puutteellisesti. Throws-lauseita ei välttämättä ole merkitty dokumenttiin johdonmukaisesti. Voidaan linjata, että suunnitteludokumentissa ei tarvitse olla näitä tietoja (tarkasti), jos ne ovat Javadocissa täydellisesti, vaan suunnitteludokumentissa voidaan tyytyä yleisempään tekstimuotoiseen kuvailuun. API-kuvauksessa käytetty taso on kuitenkin mainittava ja perusteltava dokumentin johdannoissa. Suunnittelussa kannattaisi pitää periaatteena, että samantasoiset metodit eri komponenteissa joko heittävät poikkeuksen ulos tai käsittelevät sen sisäisesti, mutta ei satunnaisesti kummin tahansa. Testaussuunnitelmaan kirjattava selkeästi mitkä luokat testataan milläkin tavalla. Ei jätetä epäselväksi ja käytetä "mahdollisuuksien mukaan" yms. ilmaisuja. Testaus toimii laatuleimana lopputuotteelle. Suunnitelmassa tulee olla selkeä kattavuusmitta ja menetelmät kattavuuden saavuttamisen validointiin. Tärkeää on, että testausvastaava tai muut nakitut henkilöt kirjoittavat yleiset ohjeet, joita kaikki voivat noudattaa testauksessa. PHPUnit on mahdollisesti hyvä ja suositeltava framework PHP-puolen testaukseen. (Javan) lausekattavuuden selvittämiseen yksinkertaisimpia mahdollisuuksia on laittaa lohkojen loppuun tulostuslauseita (jonkinlaisella debug-optiolla), joiden avulla voidaan seurata onko tietyssä lohkossa käyty. Voidaan käyttää Javan assertia, joka voidaan kääntää päälle ja pois käännösvaiheessa tarpeen mukaan, jolloin overheadin määrä saadaan pienemmäksi. Integraatiotestaus voidaan suunnitella tarpeen mukaan kuinka vain. (Yksikkötestaus = oletusarvoisesti yhden metodin tai funktion testaus, järjestelmätestaus = vain ja ainoastaan koko järjestelmän testaus, integraatiotestaus = "kaikki muu", esimerkiksi rajapinnat kannattaa ehkä testata integraatiotestauksen nimissä.) Testauksen on oltava yksinkertaisesti toistettavissa järjestelmän kaikille luokille myös myöhemmin, joten on todennäköisesti kohtuutonta vaatia esimerkiksi Eclipsen asentamista testauksen suorittamiseksi. --------------------------------------------------------------------------------------- Lahtinen huomio, että GUI:ssa saattaa pyöriä yhtäaikaa kolme, neljä säiettä, jotka voivat kutsua samoja metodeja. Testauksen suunnittelu ja toteutus on luultavasti vaikeaa. --------------------------------------------------------------------------------------- Sarin yrittää etsiä Javalle testausframeworkkia, jonka avulla voidaan tehokkaasti selvittää testauksen lausekattavuus. Jos sopivaa ei löydy, käytetään lohkojen lopussa assertia, tai jotakin muuta menetelmää. Palomäki selvittää vastaavasti frameworkin käyttöä PHP:n kanssa. Palomäki selvittää myös Ant:n käyttöä Java-luokkien kääntämisessä. --------------------------------------------------------------------------------------- Yksikkötestauksen lausekattavuudeksi päätettiin vaatia vähintään 90% niiltä komponenteilta jotka yksikkötestataan. Testitiedostot sijoitetaan test-hakemistoon ja nimetään TestLuokanNimi. Integraatiotestausta ei todennäköisesti suoriteta. Järjestelmätestaus suoritetaan käyttötapausten pohjalta. Sovittiin GUI:n yksikkötestauksen jättämisestä kokonaan pois ainakin tässä vaiheessa. 5. Päätös Puheenjohtaja päätti kokouksen klo 12.02