WinkelkarRepository.cls.xml

Bedenking : GemaaktofferteEvent zou zo dicht mogelijk bij het dataobject moeten zitten zodat een event geraiset wordt bij het aanmaken van een offerte, aangemaakt vanuit eender welk stuk code. (bv op repository) Indien er enkel geraiset wordt vanuit verkoopservice, dan heeft de event waarschijnlijk een andere bedoeling/betekenis.

Method BewaarProductLijn(BewaarProductLijnRequest As WS.Vhisie4.Winkelkar.BewaarProductLijnRequest) geeft geen returnvalue, maw met het resultaat VoegToeproduct wordt niks gedaan. Dus ook niet nodig om dit te testen.

Melding is veraglemeend naar "ExterneId x bestaat reeds".
Daar er op data niveau geen relatie is tussen offerte en winkelkar, moet er een controle voor beide offerte en winkelkar gebeuren. Repository geeft enkel bestaat viaexterneId en het is niet de bedoeling de repository een foutmelding te laten genereren. De meldingen zitten dus op niveau van de services. 1 controle enkel op ofwel offerte of winkelkar lijkt met gevaarlijk omdat het op data niveau niet opgevangen wordt. We willen ook geen dependency creeëren tussen offerte service en winkelkar service. Vandaar elk hun controle; dus de plaats waar de controles samenkomen is dan op verkoopservice niveau. Later misschien te refactoren.

Idem als LegeKenmerken.

Okay

Winkelkar was hier niet van belang aangezien de wijzigingen en testen enkel over externid gaan. Testen zijn zoals besproken aangepast naar 1 test waarin alle controles gebeuren op de gebruikte methods binnen de MaakOfferte.

Mock & Indien = Stub

Mock met $$$ElkeWaarde not done

Wat is de nood van deze klasse ?

OfferteBewaarder mag vervangen worden door OfferteRepository - OfferteBewaarder mag eventueel integraal verwijderd worden als het niet teveel inpakt heeft

Ongebruikte lijn

Het lijkt mij beter om deze 2 aparte testen samen te nemen en daar één test van maken rekening houdend met de opmerking hierboven, dan hebben we één die de standaard use-case beschrijft.
Andere testen kunnen dan toegevoegd worden om alternatief gedrag te gaan testen

Algemenere opermerking :

De method VoegToeProduct geeft een resultaat terug dus de mock dient ook een resultaat terug te geven en dan is noodzakelijk om uw test aan te passen zodat het resultaat wordt verwerkt.

Deze testen zijn zo basic dat ik zelf de moeite niet zou doen om deze manueel te maken.
Het lijkt mij beter om ( later ) aan een systeem te werken :

• dat op zijn minst ofwel de queries gebruikt in een repository gaat controleren of die überhaupt uitvoerbaar is.
• ofwel effectief wat data gaat opzetten en uitlezen daar het gaat om een repository

Wat is het nut van deze klasse ??

Het lijkt mij voorlopig beter om de APPS.EC.Verkoop.impl.Externe.VerkoopService te gebruiken - kwestie om alles lang de verkoopservice te laten lopen

Ik zou een algemene klasse introduceren WSimpl...WinkelkarService.ExterneIdControleur die zowel de controle doet op offerte en winkelkar id