Java unit tests en visibility

door **Cycloon** » di 21 jun 2011, 17:58

317070 schreef: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.

door **317070** » ma 20 jun 2011, 20:45

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?

door **Cycloon** » ma 20 jun 2011, 20:29

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.

door **Bart** » ma 20 jun 2011, 19:59

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?

door **jhnbk** » ma 20 jun 2011, 19:17

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

door **coats001** » zo 19 jun 2011, 22:57

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.

door **Cycloon** » zo 19 jun 2011, 18:36

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.

door **Bart** » zo 19 jun 2011, 11:04

ZVdP schreef: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.

door **ZVdP** » zo 19 jun 2011, 01:32

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.

door **coats001** » zo 19 jun 2011, 00:31

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.

door **ZVdP** » do 16 jun 2011, 15:35

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.

door **coats001** » do 16 jun 2011, 15:09

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.

door **Cycloon** » wo 15 jun 2011, 19:29

coats001 schreef:Nee dat zou het niet betekenen want integratietesten raken ook methods die public zijn "dieper in de keten". Dus methods die een andere scenario "in de top" van de aanroep keten had kunnen zitten. Immers je class zit een package en elke public method kan door iedereen die je package gebruikt worden aangeroepen. Het is dus van belang dat je ALLE mogelijk scenario's (aanroep mogelijkheden) test.

Een private method kan niet anders dan via een public method worden aangeroepen. Uitgangspunt is namelijk dat je class de meest basale unit binnen Java is. De unittest is dus een test voor de werking van een class, en de werking van een class is via haar public methods gedefinieerd. ALLE logica die in private methods is gedefineerd is alleen bereikbaar via de public methods van de omvattende class. Als je dus slechts unittests schrijf voor je public methods is er geen enkele reden voor bezorgdheid dat logica vervat is de private methods kan zorgen voor "ongeteste verrassingen".

Ik kan je wel volgen en dat klopt in de meeste gevallen waar een klasse een kleine eenheid is. Dat is echter niet in alle gevallen zo. Een klasse kan soms wel eens een heel eenvoudige interface hebben, maar intern een complexe verwerking vereisen. In zo'n gevallen is het vaak lastig/onmogelijk om zinvolle testen te produceren die enkel werken via de interface. Vooral frameworkcode heeft hier wel eens last van.

door **Gast** » wo 15 jun 2011, 01:22

Ik ben het er wel mee eens dat het meestal niet zo mooi is om private methodes te testen. Deze methodes behoren tot de implementatie details van de klasse en zullen dus meestal vaker veranderen dan de interface v/d klasse (waarbij dan dus iedere keer de test mee moet worden aangepast). Daarnaast is het voor hergebruik van testcases (zie onder) en het gebruik van testen ter illustratie van hoe een klasse werkt, vaak handiger om de public, protected en package protected functionaliteit van een klasse alleen te testen via de public/protected/package protected functies, dus niet impliciet ook via tests op de private functies.

Package protected of protected functies horen wel bij de interface van de klasse. Het lijkt me een goed idee om unit tests te maken voor een utility klasse die binnen 1 package gebruikt wordt (dus waarvan alle functies package protected zijn), zoals ook voorgesteld door TS.

Voor protected functies geldt daarnaast per definitie dat ze protected zijn omdat ze overschreven moeten kunnen worden door een subklasse. Voor zowel de super klasse als de subklasse gelden vaak dezelfde set van assertions voor de protected functie (Liskov substitution principle). Er kan dus een testcase gemaakt worden die deze assertions test voor de superklasse. Deze test case kun je (of iemand anders die een subklasse bouwt van je klasse) hergebruiken voor alle subklasses.

door **coats001** » di 14 jun 2011, 11:11

Ook niet helemaal correct. Want dan zou het betekenen dat we unit test achterwege kunnen laten en voldoende hebben aan integratietests.

Nee dat zou het niet betekenen want integratietesten raken ook methods die public zijn "dieper in de keten". Dus methods die een andere scenario "in de top" van de aanroep keten had kunnen zitten. Immers je class zit een package en elke public method kan door iedereen die je package gebruikt worden aangeroepen. Het is dus van belang dat je ALLE mogelijk scenario's (aanroep mogelijkheden) test.

Een private method kan niet anders dan via een public method worden aangeroepen. Uitgangspunt is namelijk dat je class de meest basale unit binnen Java is. De unittest is dus een test voor de werking van een class, en de werking van een class is via haar public methods gedefinieerd. ALLE logica die in private methods is gedefineerd is alleen bereikbaar via de public methods van de omvattende class. Als je dus slechts unittests schrijf voor je public methods is er geen enkele reden voor bezorgdheid dat logica vervat is de private methods kan zorgen voor "ongeteste verrassingen".

Java unit tests en visibility

Plaats een reactie

Weergave uitklappen Voorafgaande berichten: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Re: Java unit tests en visibility

Contact

Community