Test.cls.xml

Uitzoeken landcodes ik maak hiervoor een kaartje aan. -> besproken met PVR. Idee om landen aan te bieden net zoals bij unishop is ok. Wordt later nog uitgewerkt.

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.

Zie uitleg CR-3. misschien later te refactoren als ook verkoopservice en dergelijke aangepakt wordt.

Belgisch adres toegevoegd.

Dit was je voorstel van testen bij het refactoren van de repository in de eerste fase vorig jaar rond de zomer. Voorlopig goed genoeg en beter dan geen.
Als we data testen gaan opzetten,dan kunnen we daar best ook een aparte package en aparte testserver voor voorzien.

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.

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

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

Zeker dat de landcodes die gaan gebruikt worden door intracto mappen op onze landcodes ?

Gebruik maken van gemeenschappelijke klasse om ExterneId te controleren

Het feit dat er op de DOM.EC.. winkelkar en APPS.VKP.Offerte een ExterneId staat is een intern gegeven dus de controle op winkelkar en offerte horen samen te zitten.
Het zou in principe niet kunnen dat de ExterneId reeds op de winkelkar staat en niet op de offerte dus is eigenlijk een controle op de offerte voldoende.
Dus de foutmelding die we naar de buitenwereld sturen is eerder één van alla "ID reeds gebruik" want intracto heeft geen weet van onze offertes en Winkelkarren.

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