...
Information about the controller can be found in this link:
Information (Dansk)
FORMÅL
------
Endpointet returnerer kundens AKTIVE el-aftaler (kontrakter) for ét bestemt
målepunkt. "serviceId" SKAL være målepunktets EAN-/aftagenummer (edielnummer),
ellers svarer kaldet ikke med korrekte data.
Svaret er en liste af aftale-objekter. Hvert objekt har felterne:
Id, ServiceId, DisplayName, AgreementType, StartDate, EndDate,
HasCapacityTariffs, Info[].
SÅDAN LÆSES TESTENE
-------------------
- Disse er MANUELLE, datakritiske tests. Trivielle kald og det, der allerede er
dækket af unit-/integrationstests, er udeladt. Fokus er på data, som kun kan
bevises mod RIGTIGE kundedata ved at sammenligne med klientprogrammet.
- Hver test beskriver HVAD værdien betyder (ikke hvor i databasen den kommer
fra) og peger på, hvor i klienten du selv kan kontrollere den.
- VIGTIGT om svarets felter (læs afsnit B FØRST): de fleste felter i svaret er
FASTE/hårdkodede og afspejler IKKE den enkelte kontrakts data. Det eneste
datadrevne signal er ANTALLET af aftaler i listen. Forveksl ikke en fast
værdi med en fejl.
- Fejl: når en test forventer, at kaldet AFVISES, skal du bekræfte, at fejlen
er synlig i SonWin-databasens log "BLOG", og at der IKKE returneres data til
kunden.
ORDLISTE (svarfelt -> klient-/kundebegreb)
------------------------------------------
Id -> målepunktets id (EAN/aftagenummer)
ServiceId -> målepunktets id (EAN/aftagenummer)
DisplayName -> produktnavn vist i klienten
AgreementType -> aftaletype
StartDate -> aftalens startdato
EndDate -> aftalens slutdato
HasCapacityTariffs -> om aftalen har kapacitetstariffer
Info[] -> supplerende oplysninger (liste af titel/nøgle/værdi)
customerId -> kundenummer
serviceId -> målepunktets EAN-/aftagenummer (edielnummer)
Tests
Unique identification
...
- Error if more than one account with the same active customerid and status for active customer
ANTAL AKTIVE AFTALER (det eneste datadrevne i svaret)
Antal aftaler svarer til kundens aktive el-aftaler
Gør: Kald endpointet med en kunde og ét af kundens målepunkter (EAN), som du
ved har præcis én aktiv el-aftale i dag.
Forvent: Listen indeholder præcis ÉT aftale-objekt.
Kontrollér i klienten: Find kunden og det pågældende målepunkt, og tæl de
kontrakter, der er gyldige i dag. Antallet i svaret skal stemme.Flere forskellige aktive aftaler giver flere objekter
Gør: Vælg et målepunkt, hvor kunden i dag har flere forskellige aktive
kontrakter (forskellige kontraktnavne).
Forvent: Ét objekt pr. forskellig aktiv kontrakt - hverken slået sammen til
ét eller blæst op med dubletter.
Kontrollér i klienten: Antal gyldige kontrakter på målepunktet i dag.Samme kontrakt med flere linjer tælles kun én gang
Gør: Vælg et målepunkt, hvor en aktiv kontrakt har flere underliggende linjer
(fx både a conto og opgørelse).
Forvent: Kontrakten optræder som ÉT objekt i listen, ikke som flere.
FASTE / HÅRDKODEDE FELTER (felter der IKKE er rigtige aftaledata)
================================================================================
(Dette afsnit beskriver bevidst begrænsningen i svaret, så du ikke fejlmelder
faste værdier som datafejl. Disse felter afspejler IKKE den enkelte kontrakt.)
B1 - Id og ServiceId er altid det indtastede målepunkt (EAN), ikke kontraktens id
Gør: Kald med et serviceId og se på Id og ServiceId i hvert objekt.
Forvent: Begge felter er nøjagtigt det EAN/serviceId, du sendte ind - ens for
alle objekter i listen, uanset hvor mange forskellige aftaler kunden har.
Kritisk fordi: Hvis en klient antager, at Id er aftalens unikke id, vil flere
aftaler se ud til at have samme id. Det er forventet i dag, men skal være
kendt af den der bruger svaret.
B2 - DisplayName er altid teksten "Dit elprodukt"
Gør: Se på DisplayName i alle objekter.
Forvent: Værdien er præcis "Dit elprodukt" i alle tilfælde - også når kundens
rigtige kontrakt hedder noget andet i klienten.
Kontrollér i klienten: Kontraktens rigtige navn vises et andet sted; det
gengives bevidst IKKE i svaret.
Kritisk fordi: En tester der sammenligner med klienten vil se forskel - det er
forventet og ikke en fejl.
B3 - AgreementType, StartDate, EndDate og HasCapacityTariffs er altid tomme
Gør: Se på disse fire felter for en aftale, hvor du i klienten KAN se en rigtig
aftaletype, start-/slutdato og evt. kapacitetstariffer.
Forvent: Alle fire felter er null/tomme i svaret, selv om dataene findes i
klienten.
Kritisk fordi: Klienten må ikke forsøge at vise aftaletype eller datoer fra
dette svar - de er bevidst ikke udfyldt. Hvis et af felterne pludselig
indeholder en værdi, er stub-adfærden brudt, og det skal undersøges.
B4 - Info er altid en tom liste (aldrig null)
Gør: Se på Info-feltet.
Forvent: Info er til stede som en TOM liste [] - aldrig null og aldrig med
indhold.
Kritisk fordi: Klienten skal kunne gennemløbe Info uden null-tjek. Bliver det
null, kan klienten fejle; får det pludselig indhold, vises uventede data.
...
Result:
Update User Account
...