Hei,
Teen dll:n class library projektina. Sitten sitä pitäisi testata ja debugata. Aiempaa dll:ääni testasin käyttäen Visual Studio 2010:n unit testing:iä. Mutta tämän uuden dll:n testaamiseen tarvitsisin käyttöliittymän ja minun pitäisi itse katsella tuloksia, ovatko ne järkeviä, niin ettei unit testin kaiketi käy (olen vielä aloittelia senkin käytösssä).
Eli minun pitää kaiketi luoda testiympäristöstä oma projekti, jossa on käyttöliittymä, johon sitten lisäisin dll:n add reference-kohdasta.
Mutta miten dll:ää pääsee debuggaamaan?
jaanas kirjoitti:
Mutta miten dll:ää pääsee debuggaamaan?
Ihan normaalisti, eli laitat sen käyntiin debug-tilassa.
Varmaan helpoin tapa on laittaa samaan solutioniin sekä dll-projekti että testausprojekti, joista jälkimmäinen startup projektiksi ja sitten vaan "start debug"
Tyhmä kysymys. Miten samaan se toinen projekti lisätään samaan solutioniin?
Oikealla on Solution Explorer ja ylimpänä "Solution 'ohjelman_nimi' ...". Klikkaa siitä oikealla -> Add -> New Project / Existing Project. Lopulta klikkaat uutta projekstia oikealla ja valitset "Set as StartUp Project".
kiitos
no eihän se kuitenkaan onnistunut. Tein ensin class library projektin. Solution explorerissa ei ole kuin sen projektin nimi debugdllkoe ja sen alla MyProject ja sitten yksi luokka. Klikkaamalla debugdllkoe tulee näkyviin kyllä add-kohta, mutta siellä ei ole add project kohtaa.
Yksikkötestauksella voi testata helposti minkä tahansa asian, joka ei edellytä esim. kuvan tai äänen tulkitsemista vaan on käsitettävissä lukuina. On melko vähän asioita, jotka vaativat välttämättä käsin testausta.
Voisinko siis sittenkin käyttää yksikkötestausta. Testauksessa pitäisi päästä katselemaan tulosvektoria, että näyttääkö se järkevältä. Ja jos ei niin, sitten säätää painokertoimia toisesta vektorista. Mutta se säätö tapahtuu sen perusteella mitä kasomalla ensimmäisestä vektorista selviää.
Eli testin onnistumisen kertoo se vaikuttaako ko. säätö myönteisesti tulokseen.
Olen käyttänyt tätä yksikkötestausta toisessa projektissa vasta pari päivää.Siinä se kyllä toimi hyvin, mutta siinä aliohjelmien tuottamat oikeat tulokset tiedttiin etukäteen ja niitä oli helppo vertailla saatuihin tuloksiin.
Siis tarkemmin asiaa ajateltuani luulen, ettei yksikkötestaus toimi. Jos teen muutoksia ohjelmaan, en voi etukäteen tietää miten painokertoimet on muutetun ohjelman tuloksien kanssa asetettava. Painokertoimien asettaminen perustuu paitsi saatuihin tuloksiin( Siihen mitä painokertoimilla pitäisi vaikuttaa), niin myös käyttäjän kokemuksiin taustalla olevasta ilmiöstä.
Eli testiympäristössä pitäisi olla mahdollisuus kokeilla eri painokerroinyhdistelmiä, josko löytyisi hyvän tuloksen antava yhdistelmä.
Yksikkötestauksella testataan, että tietty toimenpide tuottaa tietyn tuloksen. Toisin sanoen tarkoitus on testata, että koodi toimii oikein. Nyt ei ilmeisesti ollutkaan tästä kysymys.
Jäi silti hieman epäselväksi, mitä hyötyä painokerrointen viilailusta edes on, jos ohjelman lopullinen käyttäjä kuitenkin muuttaa niitä taas itse omien ilmiöidensä mukaan.
Näin minäkin vähäisellä kokemuksellani olen yksikkötestauksen käsittänyt, joten siksi en ajatellut käyttäväni sitä tämän dll:n testaamiseen.
Tästä ei voi varmuudella sanoa koodin oikeaa lopputulosta. Koodin toteaminen toimivaksi tapahtuu sen perusteella, miten hyvin testatessa nähdään painokertoimien vaikuttavan tulokseen. Jos näyttää siltä, että ne vaikuttavat myönteisesti, voi olla luottavaisella mielin sen suhteen, että käyttäjä omaa esimerkkitapaustaan laskiessaan ja omia painokertoimia siihen asettaessaan saa myös aikaan hyviä tuloksia.
Eikö tuollainen asia pitäisi miettiä kuntoon jo ennen ensimmäisenkään koodirivin kirjoittamista? Ei kuulosta kovin vakuuttavalta lähtökohdalta: "Koodasin tällaisen softan, voikohan tätä käyttää mihinkään?"
Kyllä sen ohjelman tarkoitus on hyvinkin mietitty etukäteen. Sillä on ihan kaupallista merkitystä.Siinä on useampia menetelmiä saman ongelman ratkaisemiseen ja niiden hyvyyttä pitäisi sitten vertailla testaamalla, miten hyvin ne reagoivat painokertoimiin.
Senverran olen jo testannut menetelmiä, että voin sanoa niiden toimivan odotetusti. Mutta se mikä on lopulta paras jää lopullisen käyttäjän arvioitavaksi, kun hän testaa todellisen elämän esimerkeillä.
Nyt onnistuin luomaan solutionin, jossa on kaksi projektia, toinen dll ja toinen testiympäristö. Näin saan käyttäjälle siistin ympäristön, jossa hän voi vertailla mikä menetelmistä antaa parhaan tuloksen
Aihe on jo aika vanha, joten et voi enää vastata siihen.