Lijst van teleurstellingen

[KayodeBakker]

Toegevoegd 17-04-2023

Proxy verwachtingen voor datum velden in onderzoek.

• [x] Scenario: 'burgerservicenummer' is in onderzoek en de houder velden wordt gevraagd # features\raadpleeg-met-reisdocumentnummer\gba\in-onderzoek-gba.feature:77

Verwacht verkeerde BSN

• [x] Abstract Scenario: 'reden opschorting bijhouding (67.20)' met waarde ''
  • Deze scenario verwacht 000000048 maar er wordt een insert gedaan met 000000024.

Regel 117 | >veld 2> | <waarde 2> | . <veld 2> had het moeten zijn.

• [x] Scenario: Opschorting bijhouding wordt geleverd wanneer met fields is gevraagd om '' # features\raadpleeg-met-reisdocumentnummer\gba\opschorting-bijhouding-gba.feature:94

Undefined bij inserts

• [x] .\features\raadpleeg-met-reisdocumentnummer\geheimhouding\gba\overzicht-gba.feature
• [x] .\features\zoek-met-burgerservicenummer\geheimhouding\gba\overzicht-gba.feature
  • De volgende vertalingen ontbreken:
    • indicatie geheim (70.10) = geheim_ind (afkomstig van lo3_pl)
• [x] .\features\zoek-met-burgerservicenummer\gba\actuele-reisdocumenten-gba.feature
  • De volgende vertalingen ontbreken: (afkomstig van lo3_pl_reis_doc)
    • gemeente document (82.10) = doc_gemeente_code
    • datum document (82.20) = doc_datum
    • beschrijving document (82.30) = doc_beschrijving
    • ingangsdatum geldigheid (85.10) = geldigheid_start_datum
    • datum van opneming (86.10) = opneming_datum

De volgende feature mist achtergrond gegevens voor inhoudingOfVermissing waarschijnlijk door verzoek van Kayo initieel

• [x] .\features\raadpleeg-met-reisdocumentnummer\gba\fields-gba.feature
  • Dit zorgt ervoor dat een aantal scenarios falen door de verwachting dat inhoudingOfVermissing aanwezig is. Bijv. scenario op regel 101, 102, 103

Toegevoegd 21-04-2023

Issues bij geheimhouding inserts

• [x] .\features\raadpleeg-met-reisdocumentnummer\geheimhouding\gba\overzicht-gba.feature
• [x] .\features\zoek-met-burgerservicenummer\geheimhouding\gba\overzicht-gba.feature
  • Achtergrond clashed met scenarios. Bijv. regel 84 verwacht een geheimhouding met waarde 7. De PL_ID van het reisdocument dat bij de scenario wordt gemaakt is MAX + 1, maar de genoemde persoonsgegevens is MAX + 2 want de achtergrond heeft al MAX + 1 gedaan voor lo3_pl en lo3_pl_persoon.

Onduidelijke rule

• [x] Scenario: de persoon heeft een reisdocument dat is verwijderd via de signalering opname op Register paspoortsignaleringen # features\zoek-met-burgerservicenummer\gba\actuele-reisdocumenten-gba.feature:69
  • Rule is onduidelijk. Frank heeft aangegeven dat dit een rule is waaruit moet blijken dat als een reisdocument alleen gegevens heeft uit specifieke groepen en niet uit anderen dat de reisdocument niet mag terugkomen.

Toegevoegd 02-05-2023

Dit is een bevraging op bsn niet reisdocumentnummer

• [x] .\features\raadpleeg-met-reisdocumentnummer\gba\in-onderzoek-gba.feature (Abstract Scenario: '' is in onderzoek en alleen de houder wordt gevraagd) regel 112

'010120,' is geen rubriek. Een komma bij de rubrieknummer.

• [x] Scenario: Zoek reisdocumenten op burgerservicenummer # features\zoek-met-burgerservicenummer\gba\protocollering-gba.feature:26
  • AssertionError: 080910 !== 010120, 080910: expected [ '080910' ] to have the same members as [ '010120,', '080910' ]

Achtergrond en scenario matchen niet.

• [x] Scenario: Gemeente zoekt reisdocumenten van een eigen inwoner door het opgeven van eigen gemeentecode als gemeenteVanInschrijving # features\zoek-met-burgerservicenummer\gba\autorisatie-gba.feature:45

[fsamwel]

'010120,' is geen rubriek. Een komma bij de rubrieknummer.

Scenario: Zoek reisdocumenten op burgerservicenummer # features\zoek-met-burgerservicenummer\gba\protocollering-gba.feature:26 AssertionError: 080910 !== 010120, 080910: expected [ '080910' ] to have the same members as [ '010120,', '080910' ]

@KayodeBakker deze begrijp ik niet. AssertionError: 080910, 123520 !== 010120, 080910: expected [ '080910,', '123520' ] to have the same members as [ '010120,', '080910' ]

• expected - actual

      [

• "080910,"
• "123520"
• "010120,"
• "080910" ]

Blijkbaar lever je hier 123520 als een van de zoekrubrieken. Dat is het rubrieknummer van een reisdocumentnummer. Maar hier is ZoekMetBurgerservicenummer gebruikt, dus wordt er gezocht op burgerservicenummer (010120) en gemeenteVanInschrijving (080910)

Hoe bedoel je komma in rubrieknummer? Zoekrubrieken is een komma-spatie gescheiden lijst, dus volgens mij staat dat er goed. Zie ook hoe de zoekrubrieken in de personen bevragen protocolleringsfeatures beschreven zijn

[KayodeBakker]

@fsamwel Ik krijg jouw resultaat voorbeeld niet terug in mijn resultaten overzicht. Ik leverde '010120,', '080910'. Ik snapte überhaupt al niet waarom 123520 terug kwam als verwachting (met andere woorden, ik leverde het niet maar het werd verwacht door de scenario gek genoeg.)

Wat betreft de komma, is het vrij makkelijk te zien in jouw eigen voorbeeld. De 3de item bevat een komma tussen de quotes, namelijk "010120,". Dit impliceert dat de volgende resultaat wordt verwacht: [ '010120,', '080910' ]. Zie je hoe er 1 komma tussen twee strings staan en 1 binnen 1 string? Dat is het verschil en dat is een foutieve verwachting. Nu verwacht de scenario een rubriek met een komma geplakt aan de nummers.

Aanvullend hierop blijkt dat de protocollering scenario nu werkt dus ik weet niet wat er is veranderd eerlijk gezegd. @MelvLee Heb jij een aanpassing gemaakt in de step_defs rond 2 mei of daarna?

[fsamwel]

@KayodeBakker in een vorige versie leverde de API 123520, en de verwachting was 010120. In de laatste versie van de API is dat opgelost en slaagt de feature nu