Fel i SoapUI testet "DatePeriod"

[Jesper Blomquist]

I “Assert expected records” (under “Call GetMedicationHistory datePeriod”) verifieras returnerade “records” mot “context.allRecords”. Då dessa sätts till samtliga “records” returnerade av den initiala ofiltrerade frågan, kommer den alltid validera till falskt i det fall mer än tex ett “startdatum” finns i testdatat.

Jag föreslår att raden:

“ca.assertFilteredResponse(context.allRecords, condition, recordInfo)”

ändras till:

“ca.assertFilteredResponse(ca.getContentRecords(), condition, recordInfo)”

‌

Med denna ändring verifieras bara dom “records” som faktiskt returnerades av den datum-filtrerade frågan.

[Jesper Blomquist]

detta verkar gälla fler av testerna…

[Jesper Blomquist]

ping!

[Markus Lundin]

Hej!

‌

Testsviten du refererar till använder stödlibbet som det är tänkt.

Methoden assertFilteredResponse() kontrollerar responsen emot parametrarna allRecords och filterCondition:

 * @param allRecords a list of ContentRecord objects representing the unfiltered response
 * @param filterCondition a Closure with ContentRecord as parameter to determine which records are expected
 * @param recordDescription a Closure with ContentRecord as parameter to output a string to identify each record (for error messages)
 * @param filterDescription an optional string to describe the filter parameters used (for error messages)

Underliggande logic:

public List<String> validateFilteredResponse(ContextHelperTK contextHelper) {
    def actual = contextHelper.getContentRecords().collect(recordDescription)
    def expected = this.allRecords.findAll(this.filterCondition).collect(recordDescription)

    def extra = actual.findAll{ !expected.contains(it) }.collect{"Unexpected record: " + it}
    def missing = expected.findAll { !actual.contains(it) }.collect{"Missing record: " + it}

    return extra + missing
}

‌

[Markus Lundin]

Implementerat korrekt enligt min bedömning.

[Jesper Blomquist]

Implementationen av validateFilteredResponse verkar mycket riktig korrekt, det jag vänder mig mot är med vilket dataset den anropas…

Enligt min uppfattning ser psudoflödet nu ut som följer;

ofiltrerat_svar = hämta alla utan filter
för varje “record” beräkna interval
filtrerat_svar = hämta bara vissa baserat på interval
validera ofiltrerat_svar ← här menar jag att man bara ska validera “filtrerat_svar”…

Jag har uppdaterat testets assert-kod så det ser ut som följande (enda skillnaden är att jag i sista raden kör assertFilteredResponse på den aktuella responsen (istället för på det initiala ofiltrerade svaret):

‌

import se.skl.rivta.tksupport.soapui.ContentAssertions
def ca = new ContentAssertions(context, messageExchange)

def authorTimeHead = '/urn:medicationMedicalRecord/urn1:medicationMedicalRecordHeader/urn1:accountableHealthcareProfessional/urn1:authorTime'
def authorTimeBody = '/urn:medicationMedicalRecord/urn1:medicationMedicalRecordBody/urn1:medicationPrescription/urn1:prescriber/urn1:authorTime'
def start = '/urn:medicationMedicalRecord/urn1:medicationMedicalRecordBody/urn1:medicationPrescription/urn1:startOfTreatment'
def end = '/urn:medicationMedicalRecord/urn1:medicationMedicalRecordBody/urn1:medicationPrescription/urn1:endOfTreatment'
def id = '/urn:medicationMedicalRecord/urn1:medicationMedicalRecordHeader/urn1:documentId'

def condition = { record ->
    def ordination = record.firstElementAt(authorTimeBody) ?: record.firstElementAt(start) ?: record.firstElementAt(authorTimeHead)
    def utsattning = record.firstElementAt(end) ?: "20501231235959"

    def intervalStart = [ordination, utsattning].min()
    def intervalEnd = [ordination, utsattning].max()

    def recordIsBeforeCallInterval = intervalEnd && intervalEnd[0..7] < context.datePeriodStart
    def recordIsAfterCallInterval = intervalStart && intervalStart[0..7] > context.datePeriodEnd

    return !recordIsBeforeCallInterval && !recordIsAfterCallInterval
}

def recordInfo = { record ->
    sprintf("DocumentId %s (authorTimeHeader:%s authorTimeBody:%s start:%s end:%s)", [id, authorTimeHead, authorTimeBody, start, end].collect{record.firstElementAt(it)})
}

ca.assertFilteredResponse(ca.getContentRecords(), condition, recordInfo)

‌

Förstår inte hur man annars ska kunna få igenom testet?!

‌

Mvh

Jesper - Kry

[Markus Lundin]

Hej Jesper!

Syftet med testet är att automatiskt utgå ifrån existerande data för att slippa p Så testdata kan se lite olika ut beroende på vilken testdata som används i vid körningstillfället.

Flödet du föreslår är också så flödet är. Psudoflödet som det är nu:

1. ofiltrerat_svar/allRecords = hämta alla utan filter
2. Beräkna ett antal slumpade test-interval utifrån int specad i data.xml
3. filtrerat_svar = hämta bara vissa baserat på interval

4. filtrerat_svar valideras i assertFilteredResponse(ofiltrerat_svar, condition).

   1. context.allRecords - ofiltrerat_svar, används som första parameter och är underlaget till den assertion som görs och används i combination med condition för att räkna ut vilket filtrerat svar som förväntas tillbaka.
   2. condition - Andra parametern och är reglerna för vilka poster som ska vara med i filtrerat svar och vilka som inte ska vara med i filtrerat svar.

Testet är dubbelsidigt, Vi testar alltså både vilka poster som ska vara inkluderade i responsen och vilka poster som inte ska vara inkluderade i responser.

Om testet blir rött så misstänker jag en av följande saker:

• Filtrerade svaret har filtrerat bort poster som förväntades
• Filtrerade svaret har inkluderat poster som inte förväntades

Anledningen till detta kan vara:

• Fel i tjänsten som returnerar responsen (Error meddelandet som returneras när testet felar är intressant för att kontrollera vad i testet som gick fel)
• Fel logik i condition - För att undersöka om fel logik används i condition så skulle vi kanske behöva jämföra testdata, eftersom att jag inte kan återskapa problemet med våran testdata (filtreringstestet fungerar OK med en eller flera poster i filtrerat svar).

Jag förslår att du skapar ett ärende här: https://www.inera.se/kundservice/felanmalan-och-support/

Fyll i formuläret och för snabbare hjälp är det viktigt att du anger Test och kvalitetssäkring som tjänst. Så kan vi komma till botten med problemet.

Mvh

Markus Lundin

Inera Test och kvalitetssäkring