Als developer van een client applicatie wil ik de testgevallen die staan beschreven in de features

[melsk-r]

Originally created by fsamwel (kadaster/WOZ-bevragen#72):

zodat ik:

• de relevante waarden als beschreven in de waarden.feature kan implementeren en dit kan testen
• de features kan valideren
• deze situaties met mijn client applicatie kan testen

In de features zoeken, waarden en belanghebbende naam staan testsituaties beschreven. Deze wil ik graag beschikbaar hebben als testdata in de WOZ-bevragen API.

N.B. wanneer exact dezelfde gegevens niet mogelijk of erg onhandig zijn, kunnen details (zoals identificaties) zo nodig worden aangepast in de features.

[melsk-r]

This comment originally might have been created by someone else.

Ik kan deze testdata wel overnemen en in de testdatabase zetten.

[melsk-r]

This comment originally might have been created by someone else.

Op deze woz-object nummers kan gezocht worden:

800000014669
800000003118
800000823525
800012345678

[melsk-r]

This comment originally might have been created by someone else.

@ kad-verstp als ik het goed zie zijn er nu testgevallen toegevoegd voor de feature zoeken, maar nog niet voor waarden en belanghebbende naam. Klopt dat?

[melsk-r]

This comment originally might have been created by someone else.

@ fsamwel @ kad-tromps

De genoemde woz-objectnummers hebben ook de waarden zoals het in de feature waarden stond. Hierbij moet je kijken naar de laatste paar cijfers van het objectnummer zoals 3118. (want er moest een andere gemeentecode voor.) En ik heb de namen uit de belanghebbende_naam feature gepakt. Maar de burgerservicenummer is anders.
woz-objectnummer 800012345678 is alleen voor het zoeken.

[melsk-r]

This comment originally might have been created by someone else.

Je kan niet zo maar een willekeurig WOZ object nummer opvoeren, omdat een WOZ nummer altijd begint met de relevante gemeente code. De WOZ object nummers van de eerste 3 scenario's in de waarden feature moeten dus vervangen worden met de overeenkomende identificatie zoals Priscilla ze heeft opgevoerd.

051800823525 -> 800000823525
002500003118 -> 800000003118
082600014669 -> 800000014669

De andere WOZ objecten moeten nog worden opgevoerd, en die zullen ook afwijken van hoe ze nu in de feature staan (waarschijnlijk ook allemaal beginnend met 8000). Een andere opmerking over de feature is dat beschikkingsStatussen worden terug gegeven als een set. Dus een resultaat als [ "beschikking_vernietigd", "beschikking_vernietigd" ] (regel 419) zal nooit terug komen. Een waarde met alleen de beschikking_vernietigd status wordt overigens helemaal niet terug gegeven, dus deze waarde zal niet getoond worden.

[melsk-r]

This comment originally might have been created by someone else.

WOZ object nummer 800000003118 (002500003118) resulteert in burgerservicenummer 000000085 maar moet zijn 999991234 volgens het feature.
Voor WOZ object nummer 800000014669 (082600014669) is dit 000000127 maar moet burgerservicenummer 999995678 zijn.

[melsk-r]

This comment originally might have been created by someone else.

@ kad-leenec De burgerservicenummers: 999991234 en 999995678 worden niet geaccepteerd door ons systeem omdat het niet voldoet aan de 11-proef.

[melsk-r]

This comment originally might have been created by someone else.

Zie kadaster/WOZ-bevragen#128

'waarden.feature' is n.a.v.:

Je kan niet zo maar een willekeurig WOZ object nummer opvoeren, omdat een WOZ nummer altijd begint met de relevante gemeente code. De WOZ object nummers van de eerste 3 scenario's in de waarden feature moeten dus vervangen worden met de overeenkomende identificatie zoals Priscilla ze heeft opgevoerd.

051800823525 -> 800000823525
002500003118 -> 800000003118
082600014669 -> 800000014669

aangepast.

N.a.v.:

Een waarde met alleen de beschikking_vernietigd status wordt overigens helemaal niet terug gegeven, dus deze waarde zal niet getoond worden.

heb ik sets als

    {
      "vastgesteldeWaarde": 210000,
      "waardepeildatum": "2018-01-01",
      "ingangsdatum": "2019-07-01",
      "beschikkingsStatussen": [ "beschikking_vernietigd" ]
    }

helemaal verwijderd.
De set op regel 355 heb ik nog even laten staan in afwachting van het antwoord op de vraag m.b.t.:

Een andere opmerking over de feature is dat beschikkingsStatussen worden terug gegeven als een set. Dus een resultaat als [ "beschikking_vernietigd", "beschikking_vernietigd" ] (regel 419) zal nooit terug komen.

Bedoel je dat je i.p.v.

    {
      "vastgesteldeWaarde": 437000,
      "waardepeildatum": "2019-01-01",
      "ingangsdatum": "2020-01-01",
      "beschikkingsStatussen": [ "beroep_gehandhaafd", "beroep_aangetekend" ]
    }

juist

    {
      "vastgesteldeWaarde": 437000,
      "waardepeildatum": "2019-01-01",
      "ingangsdatum": "2020-01-01",
      "beschikkingsStatussen": [ "beroep_gehandhaafd" ]
    },{
      "vastgesteldeWaarde": 437000,
      "waardepeildatum": "2019-01-01",
      "ingangsdatum": "2020-01-01",
      "beschikkingsStatussen": [ "beroep_aangetekend" ]
    }

terugkrijgt?

[melsk-r]

This comment originally might have been created by someone else.

Terug in Juli is een link en api key voor de ETO omgeving geleverd. Ik zal deze hier herhalen.

url: https://api.kadaster.nl/lvwoz-eto-apikey/api/v1/,
x-api-key: l7fd4e3e2fe8f542999507cabb91fa46fd

Als het goed is kan gemeente Den Haag hier zelf de test data aanleveren die jullie nodig hebben.

[melsk-r]

This comment originally might have been created by someone else.

Check de features en de testdata n.a.v. bovengenoemde opmerkingen met elkaar in lijn zijn.