Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-1663] SVG-038 Kleine aanpassingen tijdens het testen van Kaderdeuren

-Coordinates aangepast van zijboring voor wanneer deze x Coordinaat 0 is

[ICT-1663] SVG-038 Kleine aanpassingen tijdens het testen van Kaderdeuren

-Kleur aangepast van Tcross + coordinates + puntboring ipv rugboring

  1. … 7 more files in changeset.
[ICT-1663] SVG-038 Kleine aanpassingen tijdens het testen van Kaderdeuren

-Kleuren aangepast + posities van verschillende rotaties

  1. … 2 more files in changeset.
[ICT-1610] SVG-034 Package SvgTools verplaatsen naar TECH

-Wlipjes weg

[ICT-1610] SVG-034 Package SvgTools verplaatsen naar TECH

-De package svg tooling verplaatst naar TECH door move package zonder svnmove om fouten te voorkomen

  1. … 10 more files in changeset.
[ICT-1367] SVG-030 Aanmaken BoringElementFactory

-specifiekere getallen bij aanroepen methodes + dummyObjecten + groeperen

  1. … 1 more file in changeset.
Deze method hoort niet thuis in deze klasse, want heeft niets met BeslagBoringen te maken. We zullen samen bekijken hoe we dit best kunnen afsplitsen.

Deze method hoort niet thuis in deze klasse, want heeft niets met BeslagBoringen te maken.
We zullen samen bekijken hoe we dit best kunnen afsplitsen.

Na een Catch() moet er altijd een "reporting" of een nieuwe throw gedaan worden. In dit geval zegt mijn gevoel dat hier geen try-catch moet staan, want het is aan de gebruiker/oproepende code om ze...

Na een Catch() moet er altijd een "reporting" of een nieuwe throw gedaan worden.
In dit geval zegt mijn gevoel dat hier geen try-catch moet staan, want het is aan de gebruiker/oproepende code om zelf te bepalen welke error-handling er nodig is.

Anderszijds lijkt dit meer op een stukje test-code, dan kan je dat best ook zo aangeven (in methodnaam of ev in de comment) of moet je deze testcode verplaatsen naar een zTryout-klasse.
Zo niet, dan krijg je de reviewer(s) op uw dak :-D

beetje muggeziften, maar maakt de method wel iets overzichtlijker : --> zet de 2 lijnen met Doorboring.SvgBox mee bovenaan, dan staan de (3) lijnen met Doorboring-object bij elkaar en de (3) lijnen...

beetje muggeziften, maar maakt de method wel iets overzichtlijker :
--> zet de 2 lijnen met Doorboring.SvgBox mee bovenaan, dan staan de (3) lijnen met Doorboring-object bij elkaar en de (3) lijnen met Circle-object staan dan ook bij elkaar.

Een andere volgorde, op basis van een andere logica, is wellicht ook oké.

Deze klasse mag idd weg.

Deze klasse mag idd weg.

Zelfde opmerking als bij ICT-1374 CrossFactory UT : Welgemikte getallen kiezen : bvb MaakBoring (60, 40, 5, Kleur.blauw) Een essentiele verantwoordelijkheid van de UT is om bij (x,y)-coordinaten e...

Zelfde opmerking als bij ICT-1374 CrossFactory UT :
Welgemikte getallen kiezen : bvb MaakBoring (60, 40, 5, Kleur.blauw)

Een essentiele verantwoordelijkheid van de UT is om bij (x,y)-coordinaten een foutieve (y,x)-switch te detecteren.

Zelfde opmerking als bij ICT-1374 CrossFactory UT : DummyCirkel en (misschien) DummySvgBox --> dit laatste is mogelijk een beetje tricky :-P

Zelfde opmerking als bij ICT-1374 CrossFactory UT :
DummyCirkel en (misschien) DummySvgBox --> dit laatste is mogelijk een beetje tricky :-P

Bij iedere UT moet je denken "Kan deze setup fouten verbergen?" of anders gezegd "Kan ik een programmeerfout aan het licht brengen, puur door andere input te kiezen?" Dus de (30, 30) zou je beter ...

Bij iedere UT moet je denken "Kan deze setup fouten verbergen?" of anders gezegd
"Kan ik een programmeerfout aan het licht brengen, puur door andere input te kiezen?"

Dus de (30, 30) zou je beter aanpassen naar verschillende waarden (zoals bvb. erboven 25,30)

Zoals het er nu staat, kan je enigszins verwarring scheppen tussen de echte MaakLijn() en de VerwachtMethodCall, aangezien deze (eerste) dezelfde parameters hebben. Bij voorkeur 2 verschillende (du...

Zoals het er nu staat, kan je enigszins verwarring scheppen tussen de echte MaakLijn() en de VerwachtMethodCall, aangezien deze (eerste) dezelfde parameters hebben.
Bij voorkeur 2 verschillende (dummy) Lijn-objecten gebruiken bij de DanReturn :

DummyLine1 = MaakLijn(0,0,0,0)
DummyLine2 = MaakLijn(0,0,0,0)

Ge hebt een Assign en Act gedeelte, maar genen Assert. Deze test doet dus eigenlijk niets

Ge hebt een Assign en Act gedeelte, maar genen Assert. Deze test doet dus eigenlijk niets

Deze locatie gaat ge toch ergens in een ConfigItem moeten steken en niet zo hardcoded laten staan

Deze locatie gaat ge toch ergens in een ConfigItem moeten steken en niet zo hardcoded laten staan