About
The tests in this class applies to the agreement controller.
In SonWIn terms, an account is somewhat equivilant to an AKUNDE record.
Included in the tests for this controller is the Common Data Tests.
Information
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
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.