Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-2882] Uitloop Legrabox PS-M en TS-M

- TS-M verwijderen in configuraties en vervangen door CS-M

  1. … 1 more file in changeset.
[ICT-1546] PM: Maatwerk: Space Step: Ingegeven Kenmerken Caché-kant inbouwen

- Test voor convertoren toevoegen

  1. … 6 more files in changeset.
[UST4096] LBX: MeenemerSet voor binnenlade: APPS-enum - default van leeg naar Zonder:
[UST4096] LBX: MeenemerSet voor binnenlade: APPS-enum - default van leeg naar Zonder:
Moet DOM enu zijn. en dan zal bijhorende test ook moeten aangepast worden. Zie mail.

Moet DOM enu zijn.
en dan zal bijhorende test ook moeten aangepast worden. Zie mail.

[UST4096] LBX: MeenemerSet voor binnenlade: APPS-enum - default van leeg naar Zonder:

- Conversie MeenemerSet tussen ECON en APPS

- Conversie MeenemerSet tussen EXT en APPS

- Conversie MeenemerSet tussen EDI en APPS

  1. … 5 more files in changeset.
[UST3954] TAX-SY: herschikken van de LBX-testen (converters)

- vhTest.Utils Edi-kenmerken GewoneCLadeOriongrijs() geen binnenlade-properties

- vhTest.Utils Ext-kenmerken GewoneCLadeOriongrijs() geen binnenlade-properties

  1. … 1 more file in changeset.
Opgekuist (tijdens development gaf dit nog problemen, nu blijkbaar ni meer, dus terug leeg http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif )

Opgekuist (tijdens development gaf dit nog problemen, nu blijkbaar ni meer, dus terug leeg )

Ik snap de redenering maar ik vind dit niet correct. Mss eens in de groep gooien en beslissen wat we hiermee doen?

Ik snap de redenering maar ik vind dit niet correct. Mss eens in de groep gooien en beslissen wat we hiermee doen?

Er zijn (in een tamelijk recent verleden) helaas 2 versies van de "StandaardLade" ontstaan. En blijkbaar stonden nog niet alle converters aan elkaar geschakeld in de UT's voor die converters. Om éé...

Er zijn (in een tamelijk recent verleden) helaas 2 versies van de "StandaardLade" ontstaan. En blijkbaar stonden nog niet alle converters aan elkaar geschakeld in de UT's voor die converters.
Om één grote ketting van UT's te kunnen maken, moest de StandaardLade wel overal dezelfde kenmerken hebben.

Daarom heb ik in deze test de bestaande "StandaardLade" gedegradeerd tot een "GewoneCLadeOriongrijs", zodat duidelijk is dat dit NIET meer de standaardlade is.
Deze method wordt echter nog wel gebruikt in een aantal andere testen --> dus ook vhTestFiles, dus volledig aanpassen naar de nieuwe StandaardLade zou veel meer werk zijn t.o.v. alleen de methodnaam te wijzigen en bestaande tests+testresults te behouden.
De nieuwe "StandaardLade" in deze klasse is nu wel conform met de rest "APPS - DOM - EXT - EDI - ECON - ..."

De testmethod voor de standaardlade staat nu inderdaad dubbel. Dus ik heb ze in deze klasse verwijderd. Wat de ZijkantLogo-testen van Kurt betreft, daar ga ik wel afblijven, hé http://subversion02...

De testmethod voor de standaardlade staat nu inderdaad dubbel. Dus ik heb ze in deze klasse verwijderd.

Wat de ZijkantLogo-testen van Kurt betreft, daar ga ik wel afblijven, hé

Vond het eerst zelf ook een beetje vreemd, waarom da aangepast is :-P Verklaring vrij eenvoudig : Naam moet consistent zijn met de andere vhTest.Utils ... Kenmerken() klassen, omdat de UT's voor de...

Vond het eerst zelf ook een beetje vreemd, waarom da aangepast is :-P
Verklaring vrij eenvoudig :
Naam moet consistent zijn met de andere vhTest.Utils ... Kenmerken() klassen, omdat de UT's voor de convertoren dit oproepen:

Method "Test: TAX Standaardlade"()
{
Do ..AssertConverter("StandaardLade")
}

Method "Test: TAX BinnenLade"()
{
Do ..AssertConverter("BinnenLade")
}

Method "Test: TAX LadeMetVeelExtras"()
{
Do ..AssertConverter("LadeMetVeelExtras")
}

Anders falen de UT's ... spijtig genoeg. (normaal gezien moet dan de UT-impl aangepast worden en niet de code, maar deze wijziging heeft geen invloed op de werking van de nietmeeleverens, denk.) De...

Anders falen de UT's ... spijtig genoeg.
(normaal gezien moet dan de UT-impl aangepast worden en niet de code, maar deze wijziging heeft geen invloed op de werking van de nietmeeleverens, denk.)
Deze tactiek was ook al toegepast bij LBX door één van m'n voorgangers.

De "ByRef" is hier om aan te geven dat het EconKenmerken-object zal aangepast worden. Technisch is het niet fout om da als .local door te geven. Objecten worden trouwens altijd als "pointer naar ge...

De "ByRef" is hier om aan te geven dat het EconKenmerken-object zal aangepast worden.
Technisch is het niet fout om da als .local door te geven. Objecten worden trouwens altijd als "pointer naar geheugenplaats" doorgegeven.

Principe is bovendien overgenomen van de 2 lijnen eronder, en dat leek mij niet verkeerd om het zo aan te duiden.

Laat zeker weten als je hier toch aan twijfelt.

Zal bij volgende opkuis verwijderd worden.

Zal bij volgende opkuis verwijderd worden.

Vreemd dat deze klasse in de review van UST3954 zit, want is gecommit onder UST3942 :-? Hoe dan ook : nieuwe UT toegevoegd, maar ook gecommit onder UST3942 . De review heb ik wel hier toegevoegd, w...

Vreemd dat deze klasse in de review van UST3954 zit, want is gecommit onder UST3942 :-?
Hoe dan ook : nieuwe UT toegevoegd, maar ook gecommit onder UST3942 .
De review heb ik wel hier toegevoegd, want gij hebt er achter gevraagd :-D :-D

Er is een testcase waarbij verpakking probox moet geconverteerd worden. Dit moet uiteraard probox blijven! *vhUnitTest.EXT.Unishop.PurchaseOrder001.ProductConverter.ExtNaarEdi.Tax.Test.cls(Test: ...

Er is een testcase waarbij verpakking probox moet geconverteerd worden. Dit moet uiteraard probox blijven!

  • vhUnitTest.EXT.Unishop.PurchaseOrder001.ProductConverter.ExtNaarEdi.Tax.Test.cls(Test: TAX LadeMetVeelExtras)
    Maar ik maak een nieuwe testmethod bij, die controleert of verpakking "" wordt geconverteerd naar V1.
in volgende fase wordt dit opgekuist http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

in volgende fase wordt dit opgekuist

Bij volgende update mag dit definitief verdwijnen.

Bij volgende update mag dit definitief verdwijnen.

Klopt, maar is in een ander kanban-kaartje, dus ook aparte review

Klopt, maar is in een ander kanban-kaartje, dus ook aparte review

moet de omgekeerde in APPS.PM.Maatwerk.impl.NaarObjectConverterTAX ook niet nog aangepast worden?

moet de omgekeerde in APPS.PM.Maatwerk.impl.NaarObjectConverterTAX ook niet nog aangepast worden?

idem

idem

mag dit niet gewoon weg?

mag dit niet gewoon weg?