Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
TestFiles reviewen, is in dit soort stories bijna onbegonnen werk. Ik heb zo goed en zo kwaad mogelijk de changes bekeken. Alvast bedankt om het aantal testfiles te filteren. Het geheel lijkt me we...

TestFiles reviewen, is in dit soort stories bijna onbegonnen werk. Ik heb zo goed en zo kwaad mogelijk de changes bekeken.
Alvast bedankt om het aantal testfiles te filteren.
Het geheel lijkt me wel oké te zijn.

Ook in eCon enkele commits gereviewed.

De dossiercode "LI7K" was blijkbaar een onbedoelde tussenstap (Tricky situatie met de TAOR Losse componenten) In combinatie met svn rev. 69413 is dit wel een correcte overgang. Hierbij is deze cha...

De dossiercode "LI7K" was blijkbaar een onbedoelde tussenstap (Tricky situatie met de TAOR Losse componenten)
In combinatie met svn rev. 69413 is dit wel een correcte overgang.

Hierbij is deze change nagekeken en goedgekeurd!

De meeste testfiles heb ik maar buiten de review gehouden. Een aantal zijn toch toegevoegd, bij wijze van check van het resultaat is dat, denk ik, wel ok en het is bovendien soms ook moeilijk om ui...

De meeste testfiles heb ik maar buiten de review gehouden. Een aantal zijn toch toegevoegd, bij wijze van check van het resultaat is dat, denk ik, wel ok en het is bovendien soms ook moeilijk om uit te maken a.d.h.v. de changesets of het al dan niet over code gaat of testfiles.
P.s.: Ook kleine change in Econ (zie svn).

[ICT-3120] [rvWV] PM: TAX: Front HoogteVerstelling MoventoKoppeling: release alle klanten:
[ICT-3120] [rvWV] PM: TAX: Front HoogteVerstelling MoventoKoppeling: release alle klanten:
[ICT-2581] [rvWV] HX: TAX: Movento-koppeling: Aanpassing ProductCreatie volgens KoppelingType:
[ICT-2581] [rvWV] HX: TAX: Movento-koppeling: Aanpassing ProductCreatie volgens KoppelingType:
Heum... waarom? Die verandert toch nooit en hoeft tussen UTs toch ook niet eventueel te veranderen? Toch zeker niet sinds er in de constructor ervan niets meer gebeurt. Ik dacht dat een OnBeforeOne...

Heum... waarom? Die verandert toch nooit en hoeft tussen UTs toch ook niet eventueel te veranderen? Toch zeker niet sinds er in de constructor ervan niets meer gebeurt.
Ik dacht dat een OnBeforeOneTest bedoeld is voor als er een gevaar is dat hij door eerdere UTs zou kunnen bevuild worden, wat hier niet het geval is.

Bwa, is een beetje zo gegroeid door refactoren... Waarom een Bepaler new'en per UnitTest, als je hem gewoon 1 keer kunt new'en in een OnBeforeAllTests? Daarna de afweging: Waarom dan nog de call on...

Bwa, is een beetje zo gegroeid door refactoren...
Waarom een Bepaler new'en per UnitTest, als je hem gewoon 1 keer kunt new'en in een OnBeforeAllTests?
Daarna de afweging: Waarom dan nog de call onder test speciaal gaan afzonderen? En bovendien: Waarom beschikken we anders over een $$$AssertTrue en $$$AssertFalse?
Het was bovendien daardoor ook niet meer nodig om een betekenisvolle, extra lokale variabele te voorzien in de UnitTesten (VerwachtInOpstartfase), dus ook al een regel minder per UT, zonder aan leesbaarheid in te boeten (eerder het tegendeel).
Doe de nieuwe versie eens open in studio en zie eens hoe leesbaar die is
Misschien moeten we dan eerder (mettertijd, als die klassen eens onder change komen) die van LBX en TBX aanpassen naar dit model?

Ik had verwacht dat "Product" of "ProductId" reeds werd doorgeven via de LadeInfo, maar dat blijkt toch niet het geval. Als dit wel zo was, dan had het niet nodig geweest om de extra parameter (pro...

Ik had verwacht dat "Product" of "ProductId" reeds werd doorgeven via de LadeInfo, maar dat blijkt toch niet het geval.
Als dit wel zo was, dan had het niet nodig geweest om de extra parameter (productieSequentie) toe te voegen.
Na al je inspanningen, keur ik deze oplossing goed

Ik begrijp niet echt waarom je deze "Assert..." method hebt weggewerkt. Dit is immers een algemeen gebruikt principe, o.a. om aan te geven dat de test-methods in deze klasse dezelfde logica oproepe...

Ik begrijp niet echt waarom je deze "Assert..." method hebt weggewerkt.
Dit is immers een algemeen gebruikt principe, o.a. om aan te geven dat de test-methods in deze klasse dezelfde logica oproepen. Hoe eenvoudig deze ook is.

En voor zover consistentie een argument i : de implementatie bij TAX is nu minder consistent met die van LBX en TBX.

Ik vind dit geen drama, hoor. Als je wilt kunnen we hierover van gedachten wisselen

Kleine suggestie : OpstartfaseBepaler voor iedere test(method) newen, dat is ietsje properder --> dus in de OnBeforeOneTest() is beter. Let op: parameter (aTestCase) !

Kleine suggestie :
OpstartfaseBepaler voor iedere test(method) newen, dat is ietsje properder --> dus in de OnBeforeOneTest() is beter.
Let op: parameter (aTestCase) !

ineens een Set van maken, lijn wordt korter en leesbaarder

ineens een Set van maken, lijn wordt korter en leesbaarder

[ICT-2144] [rvWV] HX: TAX koppeling: hoogteverstelling pilootklanten productieaansturing...
[ICT-2144] [rvWV] HX: TAX koppeling: hoogteverstelling pilootklanten productieaansturing...
Reden van deze wijzigingen : method .GeefProductSpecificatie() kan antwoorden met een leeg object. Wanneer men hierop meteen .GeefIngegevenKenmerken() oproept, crasht caché met een "InvalidOref" en...

Reden van deze wijzigingen :
method .GeefProductSpecificatie() kan antwoorden met een leeg object.
Wanneer men hierop meteen .GeefIngegevenKenmerken() oproept, crasht caché met een "InvalidOref" en geen enkele notie over welk product het gaat.
In de rechtstreekse implementatie van .GeefIngegevenKenmerken() is deze fout wel goed opgevangen, en zal een leesbare foutmelding gesmeten worden.

[ICT-1976] PM: MaatwerkProduct heeft geen IngegevenKenmerken (cfr. SST-LBX)
[ICT-1976] PM: MaatwerkProduct heeft geen IngegevenKenmerken (cfr. SST-LBX)
zie TAOR-opmerking hieronder

zie TAOR-opmerking hieronder

Hier mag je gerust Quit ..Product.GeefProductSpecificatie().GeefIngegevenKenmerken().GeefLadeCode() van maken. Dat is minstens even leesbaar.

Hier mag je gerust
Quit ..Product.GeefProductSpecificatie().GeefIngegevenKenmerken().GeefLadeCode() van maken. Dat is minstens even leesbaar.

dingen die in zTryout zitten, moet je niet mee in de review steken

dingen die in zTryout zitten, moet je niet mee in de review steken

in principe niet met echte producten testen. gebruik vhTest.Utils.DOM.PM.Product om producten aan te maken voor en weer te verwijderen na je test (idem bij andere schuiven)

in principe niet met echte producten testen.

gebruik vhTest.Utils.DOM.PM.Product om producten aan te maken voor en weer te verwijderen na je test (idem bij andere schuiven)

ProductApi.New() ipv domeincentext

ProductApi.New() ipv domeincentext