Java unit tests en visibility

[coats001]

Beste Cycloon, naar mijn inziens maakt het niet uit hoe eenvoudig de interface is en hoe ingewikkeld de interne logica is. Feit blijft dat logica slecht via de interface (zijnde de public methods) van de class ontsloten kan en dus getest dient worden. Immers logica/code die niet toegankelijk is hoeft niet getest te worden. De enige toegang tot code/logica van een class is haar public methods.

[ZVdP]

Dat vind ik toch ook kort door de bocht hoor, coats001.

Stel ik heb zoiets

Code: Selecteer alles

public int myMethod(int a,int b)

{

  return method2(method1(a))+method3(a,b);

}

private int method1(int a)

{

 ...

}

private int method2(int a)

{

 ...

}

private int method3(int a,int b)

{

 ...

}

En een van mijn assertions mislukt voor myMethod.

Bij een goede unittest zou ik moeten kunnen zien waar de fout zit. Ik heb geen idee nu; method1,method2,method3 of myMethod zelf.

Als ik nu de private methods method1,method2 en method3 eerst had getest, dan had ik ofwel daar al een assertion failure tegengekomen, ofwel kon in nu makkelijk besluiten dat de fout in myMethod moet zitten.

Zonder die tests moet ik dat zelf nog gaan uitzoeken.

[coats001]

Uiteraard kan je in bovenstaand geval wel zien waar het fout gaat in de code als er assertion mislukt op myMethod. Een unittest op een private method voegt niets toe.

[ZVdP]

Hoe dan?

assertEquals(5,myMethod(1,4)) geeft false. Dat is alles wat ik krijg. Ik mag nu zelf heel mijn code overlopen om te zien in welke methode(s) er een fout zit.

[Bart]

Hoe dan?

assertEquals(5,myMethod(1,4)) geeft false. Dat is alles wat ik krijg. Ik mag nu zelf heel mijn code overlopen om te zien in welke methode(s) er een fout zit.

Je moet unit testing niet verwarren met de moeilijkheidsgraad van het debuggen van je code. Vergeet daarnaast niet dat er ook een fout in je unit test kan zitten.

[Cycloon]

Je moet unit testing niet verwarren met de moeilijkheidsgraad van het debuggen van je code. Vergeet daarnaast niet dat er ook een fout in je unit test kan zitten.

Een unit test zou wel een zo klein mogelijk op zichzelf staand deeltje code moeten testen. Wanneer een assertion faalt moet het direct duidelijk zijn waarom die faalt. Als dit niet duidelijk is dan ben je simpelweg niet meer bezig met unit testing maar eerder met integratietesten.

[coats001]

Een unit test zou wel een zo klein mogelijk op zichzelf staand deeltje code moeten testen. Wanneer een assertion faalt moet het direct duidelijk zijn waarom die faalt. Als dit niet duidelijk is dan ben je simpelweg niet meer bezig met unit testing maar eerder met integratietesten.

Een private method is geen op zichzelf staand eenheid, immers slecht via een public method kan het zijn?/haar? functie uitoefenen. Eigenlijk is logisch gezien een private method gewoon onderdeel van een public method, puur om structurele reden(leesbaarheid en/of lokale class-interne herbruikbaarheid) is er gekozen of de code aftesplitsen.

[jhnbk]

Waarom zou elke private method zijn afgesplitst om leesbaarheid te bevorderen of iets structureels op te lossen?

[Bart]

Waarom zou elke private method zijn afgesplitst om leesbaarheid te bevorderen of iets structureels op te lossen?

Waar zou je een private method anders voor willen gebruiken dan de punten die coats001 aandraagt?

[Cycloon]

Het feit dat je iets gaat afzonderen voor hergebruik wil zeggen dat dit een kleine unit is die op zichzelf staat. Dit betekent dan ook dat die hoort getest te worden op zijn pre en postcondities.

[317070]

Het feit dat je iets gaat afzonderen voor hergebruik wil zeggen dat dit een kleine unit is die op zichzelf staat. Dit betekent dan ook dat die hoort getest te worden op zijn pre en postcondities.

Dat is het hem juist, hij staat wel op zichzelf maar wordt slechts binnen een erg beperkte context gebruikt.

Maar dat hangt er ook van af van wat de testfilosofie is die je wil gebruiken, lijkt mij. Als je aan unit testing doet, moet je nog steeds je unit bepalen. Als je unit de methoden zijn, dan test je de private methode wel, als je unit de klasse is, dan test je de private methode niet. Toch?

[Cycloon]

Dat is het hem juist, hij staat wel op zichzelf maar wordt slechts binnen een erg beperkte context gebruikt.

Maar dat hangt er ook van af van wat de testfilosofie is die je wil gebruiken, lijkt mij. Als je aan unit testing doet, moet je nog steeds je unit bepalen. Als je unit de methoden zijn, dan test je de private methode wel, als je unit de klasse is, dan test je de private methode niet. Toch?

Alles binnen de informatica draait uiteindelijk wel rond filosofie. Maar ik blijf toch wel bij het standpunt dat van zodra je iets onder brengt in een method dat dit betekent dat dit een opzichzelf staand geheel is. Er zijn uiteraard af en toe wel uitzonderingen. Dan denk ik bv. aan methods die enkel gebruikt worden voor design redenen (bv. een visitor pattern). Een klasse is iets dat véél ruimer is. Het is iets dat staten en een gedrag heeft. Dat geeft dus al aan dat een klasse geen kleine unit meer is, het is al bijna een klein systeem op zich.