Tuotanto- ja testijärjestelmän avoimuuden eriyttäminen?

[pe3]

Päivitetty selkeämmäksi 29.11

Antaessaan mahdollisuuden kuitata (ainakin?) testattavuus-vaatimuksen testijärjestelmällä, vähintäänkin hämärtyy mitä määritelmän käsitteellä "rajapinta" tarkalleenottaen tarkoitetaan. Jos kerran "rajapinta" on testattava, kun tarjotaan pääsy testijärjestelmään, alkaa testijärjestelmä kuulostaa rajapinnan osalta, "tuotantojärjestelmän" rinnalla.

Mitä on "testattavuus", joka välillä toteutuu pääsyllä tuotantojärjestelmään ja välillä testijärjestelmään? Järjestelmään tietoa tallentavan ohjelman kehittämisessä pääsy pelkästään aitoa dataa sisältävään tuotantojärjestelmään, olisi testattavuuden kannalta vähintäänkin hankalaa, sillä testit sotkisivat aitoa dataa.

Tuntuisi paremmalta ratkaisulta 1) käsitellä erikseen tuotantojärjestelmän ja testijärjestelmän rajapinnan avoimuutta ja 2) kertoa erillisen testijärjestelmän tarpeellisuudesta ja mahdollisuuksista, ilman että määritelmä itse kytkee näitä yhteen. Tämä voisi myöskin lisätä määritelmän hyödyllisyyttä hankkeiden avoimuusasteiden määrittelyssä. Voitaisiin yksiselitteisemmin esittää testiympäristön/sandboxin olevan avoin, mutta tuotantorajapinnan olevan suljetun ja vaativan esim. viranomaisen statuksen sekä sopimuksen allekirjoittamisen.

Uskoakseni testi- ja tuotantojärjetelmä ovat julkishallinnon tapauksessa usein erillisiä servereitä, sillä niiden samassa järjestelmässä (saman endpointin takana) pitäminen olisi iso riski rajapinnan onnistuneelle käyttämiselle (ettei rajapinnan käyttäjä vahingossa altistu testidatalle). Rajapinnoissa, joissa tietoavaruus on pilkottu käyttäjäkohtaisiin aliavaruuksiin, kuten GitHub:issa, oman käyttäjätunnuksen alle tallennettua dataa voi käyttää osittaiseen testaamiseen.

[apoikola]

Hyvä pointti, miten tämä pitäisi ratkaista määritelmässä? Avoin
testijärjestelmä testidatalla on kuitenkin tärkeää olla olemassa niissä
tapauksissa, joissa ei-avoimen sisällön takia ei voida antaa api-avsinta
kelle tahansa.

On Sat, 28 Nov 2015 10:22 Petri Kola [email protected] wrote:

Mielestäni on tärkeää, että määritelmässä on pyritty pysymään
määrittelemisessä yleisen toivelistan tekemisen sijaan:

Tämä määritelmä käsittelee rajapinnan avoimuutta, ei sisällön avoimuutta

Määritelmään on kuitenkin eksynyt mukaan toistuvasti esiinnouseva
epäselvyys testiaineistosta ja testijärjestelmästä.

Määritelmän avulla pitää voida käsitellä erikseen tuotantojärjestelmän ja
testijärjestelmän rajapinnan avoimuutta, ilman että määritelmä itse
pakottaa puhumaan näistä yhtenä järjestelmänä.

Uskoakseni testi- ja tuotantojärjetelmä ovat lähes aina erillisiä
servereitä, sillä niiden samassa järjestelmässä (saman endpointin takana)
pitäminen on iso riski rajapinnan onnistuneelle käyttämiselle (ettei
rajapinnan käyttäjä vahingossa altistu testidatalle). En ole itse vielä
koskaan käyttänyt pääjärjestelmää, joka sisältäisi myös testidataa.
Testidata on aina ollut omassa endpointissaan.

—
Reply to this email directly or view it on GitHub
#18.

[d2s]

Esimerkkinä testidataa käyttävästä projektista: https://github.com/futurice/op-hackathon-templates

Ymmärrettävistä syistä oikeaa dataa ei tuontyyppisissä järjestelmissä voida protovaiheessa antaa kenelle tahansa. Toisentyyppisissä tilanteissa datasettien avoimuus toisaalta on huomattavasti suurempi.

[pe3]

@apoikola heitin tonne pullarin kokeeksi.

[pe3]

Tää on varmaan niin iso muutos, että asiaa pitää pyöritellä paljonkin. Jatketaan varmaan periaatteellista keskustelua tässä säikeessä?

Toisaalta pull-requestiin voi esittää parannusehdotuksia, niin että ehdotuksesta tulisi mahdollisimman hyvä. Parannusehdotuksia voi laittaa tonne pull-requestin puolelle rivin tarkkuudella.

[apoikola]

Joo luin pullarin ja vähän tuli hmm hmm fiiliksiä. Lähinnä siinä mielessä, että määritelmä on tarkoitettu hankintatilanteisiin selvennykseksi ja hankintatilanteissa hankitaan tuotantojärjestelmiä ja pitää voida vaatia, että hankinnan kohde täyttää tämän määritelmän. Siksi oli muotoa 'testattavuus' jonka voi toteuttaa esim. testijärjestelmällä. Pitänee pohtia lisää.

[pe3]

Päivittelin issuen kuvausta paremmaksi, että issueen pääsisi paremmin sisälle. En tiiä oliko hyvä ratkaisu. Sori jos tää veti mattoa aikaisempien kommenttien alta.

[pe3]

Issue #20:n huomio "boundary" ja "interface" rajapintojen erilaisuudesta liittyy tähän issueen. Päädyin alunperin kommentoimaan, sillä tuntui oudolta, että rajapinnan avoimuudesta (endpoint ja boundary mielessä) voi sanoa jotakin toisen endpointin perusteella (tällöin kait ymmärretään rajapinta enemmän interface-mielessä).