Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-3054] [rvPVR] RVG aansturingactie: Klantetiketten
[ICT-3054] [rvPVR] RVG aansturingactie: Klantetiketten
In verband met het statement : "QR-code ... staat op dezelfde plaats op het etiket als de barcode, dus ze mogen niet beide ingevuld zijn" Optie 1 : in de software dit controleren/valideren en een ...

In verband met het statement : "QR-code ... staat op dezelfde plaats op het etiket als de barcode, dus ze mogen niet beide ingevuld zijn"

Optie 1 : in de software dit controleren/valideren en een exceptie smijten wanneer dit zich toch voordoet. De exceptie dan ook in UT opnemen : ZetVerwachteExceptie (je weet wel).
Optie 2 : in de UT tonen dat de software aanvaardt dat beide velden tegelijk ingevuld zijn, dus zonder exceptie te smijten. Hierbij wordt de verantwoordelijkheid dan naar Bartender (in dit geval) doorgeschoven.

Jij hebt hier gekozen voor Optie 2 (bewust of onbewust). Voor mij is dit oké.
Eventueel in die specifieke unit test method toelichten dat dit scenario problemen zal geven in Bartender.

[ICT-3055] VHOSS Etiket QRCode voor De Decker
[ICT-3055] VHOSS Etiket QRCode voor De Decker
Ik vermoed dat vhUnitTest.APPS.Halux.Docs.TestDataEtiketten nergens anders gebruikt wordt en dus mag opgekuist worden hé http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emo...

Ik vermoed dat vhUnitTest.APPS.Halux.Docs.TestDataEtiketten nergens anders gebruikt wordt en dus mag opgekuist worden hé

Info2 wordt wel geassert, maar doet niet echt ter zake in deze UT. Toch niet volgens de naam ervan.

Info2 wordt wel geassert, maar doet niet echt ter zake in deze UT. Toch niet volgens de naam ervan.

Ik zou de UT-naam iets duidelijker maken, want "Klant OrderNummer" houdt eigenlijk pas steek als voorgaande UT in acht wordt genomen en mettertijd staan die 2 UT misschien niet meer vlak bij elkaar...

Ik zou de UT-naam iets duidelijker maken, want "Klant OrderNummer" houdt eigenlijk pas steek als voorgaande UT in acht wordt genomen en mettertijd staan die 2 UT misschien niet meer vlak bij elkaar. Ik zou ook, net zoals hierboven, vermelden dat het over het veld Info1 gaat.

Misschien nog bijzetten "in Info1";

Misschien nog bijzetten "in Info1";

Ofwel klopt de naam van de UT niet, ofwel de implementatie. Er is geen assert op ProductImg en als ik die toevoeg (met een verwachte waarde anders dan leeg), dan slaagt de test, terwijl ProductImg ...

Ofwel klopt de naam van de UT niet, ofwel de implementatie. Er is geen assert op ProductImg en als ik die toevoeg (met een verwachte waarde anders dan leeg), dan slaagt de test, terwijl ProductImg volgens de UT-naam leeg zou moeten zijn!
In de "oude" UT ontbrak die assert blijkbaar ook en de UT-naam is ongewijzigd volgens deze review, dus zou er eens nagevraagd/nagekeken moeten worden wat eigenlijk de bedoeling is, zodat het juiste kan aangepast worden.

Ik zou de projectreferentie hier en in de volgende Unit Test vooraf in een variabele steken met een duidende naam, zodat het wat meer opvalt. Duurde even voordat ik doorhad dat in de volgende UnitT...

Ik zou de projectreferentie hier en in de volgende Unit Test vooraf in een variabele steken met een duidende naam, zodat het wat meer opvalt. Duurde even voordat ik doorhad dat in de volgende UnitTest het 2-tje weg was en aangezien dàt het enige verschil is mag het wel wat opvallen

Is het niet een beetje raar dat deze properties nu leeg zijn voor de assert? Worden blijkbaar niet mee uitgemockt?

Is het niet een beetje raar dat deze properties nu leeg zijn voor de assert? Worden blijkbaar niet mee uitgemockt?

[ICT-449] UST3816 - [rvTHB] Deel 2 van Tests die klanten maken: schijfruimte-probl: tests onafh van...
[ICT-449] UST3816 - [rvTHB] Deel 2 van Tests die klanten maken: schijfruimte-probl: tests onafh van...
Ik denk dat dit veel extra werk zou opleveren en niet waard zou zijn kosten/baten

Ik denk dat dit veel extra werk zou opleveren en niet waard zou zijn kosten/baten

Door de bestaande testen aan te passen heb je het gedrag waarbij de laatste parameter de default is, weggemoffeld. Je moet de originele testen laten staan en een paar nieuwe testen maken die True a...

Door de bestaande testen aan te passen heb je het gedrag waarbij de laatste parameter de default is, weggemoffeld. Je moet de originele testen laten staan en een paar nieuwe testen maken die True als laatste parameter hebben.

{$$$False} ipv 0

{$$$False} ipv 0

Kan die nieuwe property eigenlijk niet mee op de UitvoeringInfo gestoken worden? In principe staan daar nog allerlei gegevens die nodig zijn om (in dit geval) etiketten af te drukken. Op die manier...

Kan die nieuwe property eigenlijk niet mee op de UitvoeringInfo gestoken worden? In principe staan daar nog allerlei gegevens die nodig zijn om (in dit geval) etiketten af te drukken. Op die manier houden we de interface(s) proper (zeker als er ooit nog andere parameters bij moeten komen).

Dit geldt ook voor sommige andere methods/klasses in deze review

comments weg

comments weg

[IC-1732] Implementatie SpaceStep Klantetiket
[IC-1732] Implementatie SpaceStep Klantetiket
is inderdaad onterecht gecommit. In de huidige versie staan de tests weer actief trouwens

is inderdaad onterecht gecommit. In de huidige versie staan de tests weer actief trouwens

dat dit een vhossetiket is dat afleidt van een normaal etiket. De vhossvelden worden achteraan toegevoegd.

dat dit een vhossetiket is dat afleidt van een normaal etiket. De vhossvelden worden achteraan toegevoegd.