search

okffi / open-api-definition

Community governed definition of open API
http://okffi.github.io/open-api-definition/
Creative Commons Zero v1.0 Universal
7 stars 7 forks source link

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

Open pe3 opened 8 years ago

pe3 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/okffi/open-api-definition/issues/18.

d2s commented 8 years ago

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 commented 8 years ago

@apoikola heitin tonne pullarin kokeeksi.

pe3 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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ä).