Comment Search

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

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

Wat is het nut van deze klasse ??

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.

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

Mock met $$$ElkeWaarde not done

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.

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

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

Is eigenlijk een beetje muggenziften maar het zou nog dat tikkeltje beter zijn mocht de code er ongeveer zo uitzien

do ..AssertEdiNaarEcon(##class(vhTest.Utils.APPS.EDI.common.dto.LadeTBX).StandaardLade(),##class(vhTest.Utils.ECON.PM.Maatwerk.dto.TbxKenmerken).StandaardLade())

waarom zijn dit geen kenmerken van een standaardlade kwestie van toch iets volledig terug te geven naar intracto

Overbodige lijn

Overbodige lijn

Waarom is dit geen enumeratie ???

Ik weet niet of het een piste is, maar het lijkt mij handig dat we enumeratie hebben van kenmerknamen in de verschillende delen, zodat de enumeratie naam hetzelfde is maar de waarde verschillend.

Kunnen dan op dat soort enumeratie een extra parameter met values zetten zodat we waarden kunnen converteren van het ene naar het andere

Dezelfde reden als vhTest.Utils.APPS.PM.Maatwerk.dto.TAORKenmerken.legekenmerken.

Okay

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.

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.

Belgisch adres toegevoegd.

Mocht dat niet zo zijn, dan stel ik voor dat we net zoals bij den unishop zelf de landen en codes aanleveren aan intracto. Wat ik wel eventueel bedenk is validaties toe te voegen op postcodes, landcodes, etc.. maar dat was niet voor deze fase dacht ik. dat zal ik es navragen.

Sinds wanneer gaan we dims vermijden ? Ze kunnen in de intermediate language misschien geen nut hebben, maar naar leesbaarheid van de code en code completion wel.

Deze code is overgenomen uit de originele dummy methods en verplaatst naar deze klasse. Altijd mogelijk om later andere data weer te geven als dat nodig blijkt te zijn.

Algemeen casing voor Set, Quit,... (niet blokkerend.)
Vraagje Wat er verder in de code gebeurd als er geen toelevering te vinden is. De verwachte datum is dan leeg. ?

$$$Elkewaarde vervangen door de te verwachten waarde.

Blumfacturen enreceptieservice naamgevingen mogen Stub of Dummy worden ipv Mock aangezien er geen verificatie is.