/ Forside / Teknologi / Udvikling / Java / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Java
#NavnPoint
molokyle 3688
Klaudi 855
strarup 740
Forvirret 660
gøgeungen 500
Teil 373
Stouenberg 360
vnc 360
pmbruun 341
10  mccracken 320
JUnit og test af private metoder
Fra : Kim Schulz


Dato : 03-05-04 10:33

hejsa
Sidder og laver tests til et projekt vha. JUnit. Nu er jeg så stødt
på det problem at jeg skal teste nogle private metoder.

Normalt ville jeg extente den klasse som indeholder de private klasser for
at få adgang til dem, men da jeg i min testklasse allerede extender
TestCase fra JUnit, så kan jeg ikke umiddebart extende.

Hvordan faen klarer man lige den?

MVH
Kim Schulz

 
 
Jonas Kongslund (03-05-2004)
Kommentar
Fra : Jonas Kongslund


Dato : 03-05-04 11:49

On Monday 03 May 2004 11:32, Kim Schulz wrote:
> Sidder og laver tests til et projekt vha. JUnit. Nu er jeg så stødt
> på det problem at jeg skal teste nogle private metoder.
>
> Normalt ville jeg extente den klasse som indeholder de private klasser for
> at få adgang til dem, men da jeg i min testklasse allerede extender
> TestCase fra JUnit, så kan jeg ikke umiddebart extende.

Subklasser kan ikke tilgå elementer, som private modifieren er anvendt på.

> Hvordan faen klarer man lige den?

Jeg vil formentligt omskrive koden så den er lettere at teste. Har du
mulighed for dette?

--
Jonas Kongslund

Kim Schulz (03-05-2004)
Kommentar
Fra : Kim Schulz


Dato : 03-05-04 12:00

In article <Msplc.27$ra1.21@news.get2net.dk>, Jonas Kongslund wrote:
> On Monday 03 May 2004 11:32, Kim Schulz wrote:
>> Sidder og laver tests til et projekt vha. JUnit. Nu er jeg så stødt
>> på det problem at jeg skal teste nogle private metoder.
>>
>> Normalt ville jeg extente den klasse som indeholder de private klasser for
>> at få adgang til dem, men da jeg i min testklasse allerede extender
>> TestCase fra JUnit, så kan jeg ikke umiddebart extende.
>
> Subklasser kan ikke tilgå elementer, som private modifieren er anvendt på.
>
>> Hvordan faen klarer man lige den?
>
> Jeg vil formentligt omskrive koden så den er lettere at teste. Har du
> mulighed for dette?


umiddelbart nej, da vi snakker 100.000 linjers kode eller mere som skal
omskrives så.

Jonas Kongslund (03-05-2004)
Kommentar
Fra : Jonas Kongslund


Dato : 03-05-04 12:40

On Monday 03 May 2004 13:00, Kim Schulz wrote:
>> Jeg vil formentligt omskrive koden så den er lettere at teste. Har du
>> mulighed for dette?
> umiddelbart nej, da vi snakker 100.000 linjers kode eller mere som skal
> omskrives så.

Det var en del. Er der tale om legacy-kode? Hvis ja, så skal det vel
alligevel ændres (hvis ikke så har jeg svært ved at se den økonomiske
genvinst i at unitteste koden)?

Man kommer i øvrigt langt med små, lokale ændringer.

--
Jonas Kongslund

Kim Schulz (03-05-2004)
Kommentar
Fra : Kim Schulz


Dato : 03-05-04 13:37

In article <Vbqlc.39$_y2.9@news.get2net.dk>, Jonas Kongslund wrote:
> On Monday 03 May 2004 13:00, Kim Schulz wrote:
>>> Jeg vil formentligt omskrive koden så den er lettere at teste. Har du
>>> mulighed for dette?
>> umiddelbart nej, da vi snakker 100.000 linjers kode eller mere som skal
>> omskrives så.
>
> Det var en del. Er der tale om legacy-kode? Hvis ja, så skal det vel
> alligevel ændres (hvis ikke så har jeg svært ved at se den økonomiske
> genvinst i at unitteste koden)?

tjaa uni projekter er sære


> Man kommer i øvrigt langt med små, lokale ændringer.

ja men det er så rigtigt mange små ændringer som skal til, og der
skal ikke meget til før det kommer til at blive noget være hack.



Jonas Kongslund (03-05-2004)
Kommentar
Fra : Jonas Kongslund


Dato : 03-05-04 15:19

On Monday 03 May 2004 14:36, Kim Schulz wrote:
> In article <Vbqlc.39$_y2.9@news.get2net.dk>, Jonas Kongslund wrote:
>> Det var en del. Er der tale om legacy-kode? Hvis ja, så skal det vel
>> alligevel ændres (hvis ikke så har jeg svært ved at se den økonomiske
>> genvinst i at unitteste koden)?
>
> tjaa uni projekter er sære

Er der tale om et kursus omhandlende test eller hur?

>> Man kommer i øvrigt langt med små, lokale ændringer.
> ja men det er så rigtigt mange små ændringer som skal til, og der
> skal ikke meget til før det kommer til at blive noget være hack.

Jeg taler om restruktureringer (refactorings), som har til formål at
forbedre designet så koden er lettere at teste. Et eksempel kunne f.eks.
være at transformere en klasse B indeholdt i en klasse A til en top-level
klasse, konvertere den til et interface, og derefter give en instans af
klasse B som argument til A's konstruktør. Begge klasser bliver lettere at
teste efter denne transformation.

Eksempel:

Følgende kode

public class A {
private B b;
public A() { ...; b = new B(); ...; }
public void foo() { ...; b.bar(); ...; }

private class B {
private void bar() {...}
}
}

transformeres til

public interface B {
void bar();
}

public class BImpl implements B {
public void bar() {...}
}

public class A {
private B b;
public A(B b) { this.b = b; ...; }
public void foo() { ...; b.bar(); ...; }
}

Man skal selvfølgelig også sørge for at rette i de klasser, der anvender A's
konstruktør. Hvis der er mange af disse så kan man vælge at bibeholde den
oprindelige konstruktør

public class A {
...
public A(B b) { super(new BImpl()); }
public A(B b) { this.b = b; ...; }
...
}

--
Jonas Kongslund

Jonas Kongslund (03-05-2004)
Kommentar
Fra : Jonas Kongslund


Dato : 03-05-04 15:24

On Monday 03 May 2004 16:18, Jonas Kongslund wrote:
> Man skal selvfølgelig også sørge for at rette i de klasser, der anvender
> A's konstruktør. Hvis der er mange af disse så kan man vælge at bibeholde
> den oprindelige konstruktør
>
> public class A {
> ...
> public A(B b) { super(new BImpl()); }

Jeg mener selvfølgelig
      public A() { this(new BImpl()); }

> public A(B b) { this.b = b; ...; }
> ...
> }
>

--
Jonas Kongslund

Kim Schulz (03-05-2004)
Kommentar
Fra : Kim Schulz


Dato : 03-05-04 15:28

In article <_wslc.1207$Jm1.52@news.get2net.dk>, Jonas Kongslund wrote:
> Er der tale om et kursus omhandlende test eller hur?

nejda semester projekt på CS@AAU

> Jeg taler om restruktureringer (refactorings), som har til formål at
> forbedre designet så koden er lettere at teste. Et eksempel kunne f.eks.
> være at transformere en klasse B indeholdt i en klasse A til en top-level
> klasse, konvertere den til et interface, og derefter give en instans af
> klasse B som argument til A's konstruktør. Begge klasser bliver lettere at
> teste efter denne transformation.
>
> Eksempel:
>
> Følgende kode
>
> public class A {
> private B b;
> public A() { ...; b = new B(); ...; }
> public void foo() { ...; b.bar(); ...; }
>
> private class B {
> private void bar() {...}
> }
> }
>
> transformeres til
>
> public interface B {
> void bar();
> }
>
> public class BImpl implements B {
> public void bar() {...}
> }
>
> public class A {
> private B b;
> public A(B b) { this.b = b; ...; }
> public void foo() { ...; b.bar(); ...; }
> }
>
> Man skal selvfølgelig også sørge for at rette i de klasser, der anvender A's
> konstruktør. Hvis der er mange af disse så kan man vælge at bibeholde den
> oprindelige konstruktør
>
> public class A {
> ...
> public A(B b) { super(new BImpl()); }
> public A(B b) { this.b = b; ...; }
> ...
> }
>

det vil så dreje sig om små 200 klasser og vi har pt kun 3 uger tilbage at
kode i, så det må blive næste gang.

MVH
Kim

Jonas Kongslund (03-05-2004)
Kommentar
Fra : Jonas Kongslund


Dato : 03-05-04 15:38

On Monday 03 May 2004 16:27, Kim Schulz wrote:
> det vil så dreje sig om små 200 klasser og vi har pt kun 3 uger tilbage at
> kode i, så det må blive næste gang.

Der skal selvfølgelig kun rettes i de klasser, som I ønsker at teste. Alt
andet vil være tidsspilde set ud fra et pragmatisk synspunkt.

--
Jonas Kongslund

Janus E (03-05-2004)
Kommentar
Fra : Janus E


Dato : 03-05-04 13:49


"Kim Schulz" <kim@schulz.dk> wrote in message
news:slrnc9c9i9.k6g.kim@homer.cs.auc.dk...
> In article <Msplc.27$ra1.21@news.get2net.dk>, Jonas Kongslund wrote:
> > On Monday 03 May 2004 11:32, Kim Schulz wrote:
> >> Sidder og laver tests til et projekt vha. JUnit. Nu er jeg så stødt
> >> på det problem at jeg skal teste nogle private metoder.
> >>
> >> Normalt ville jeg extente den klasse som indeholder de private klasser
for
> >> at få adgang til dem, men da jeg i min testklasse allerede extender
> >> TestCase fra JUnit, så kan jeg ikke umiddebart extende.
> >
> > Subklasser kan ikke tilgå elementer, som private modifieren er anvendt
på.
> >
> >> Hvordan faen klarer man lige den?
> >
> > Jeg vil formentligt omskrive koden så den er lettere at teste. Har du
> > mulighed for dette?
>
>
> umiddelbart nej, da vi snakker 100.000 linjers kode eller mere som skal
> omskrives så.

Find and Replace: "private" -> "public"

/janus


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.670 / Virus Database: 432 - Release Date: 27-04-2004



Michael Legart (03-05-2004)
Kommentar
Fra : Michael Legart


Dato : 03-05-04 14:43

On 2004-05-03, Kim Schulz <kim@schulz.dk> wrote:
>
> Normalt ville jeg extente den klasse som indeholder de private klasser for
> at få adgang til dem, men da jeg i min testklasse allerede extender
> TestCase fra JUnit, så kan jeg ikke umiddebart extende.

Jeg plejer at lave metoden protected i stedet og putte testen i samme
pakke.

--
hestdesign.info - we put the hest in .com

Jonas Meyer (03-05-2004)
Kommentar
Fra : Jonas Meyer


Dato : 03-05-04 14:53

Hej-
Kim Schulz wrote:
> hejsa
> Sidder og laver tests til et projekt vha. JUnit. Nu er jeg så stødt
> på det problem at jeg skal teste nogle private metoder.
>
> Normalt ville jeg extente den klasse som indeholder de private klasser for
> at få adgang til dem, men da jeg i min testklasse allerede extender
> TestCase fra JUnit, så kan jeg ikke umiddebart extende.
>
> Hvordan faen klarer man lige den?

Problemet er at du vil teste en private metode. Det kan du ikke, og jeg
tror ikke, det er det du vil. Tænk over hvad en private metode er - Det
er implementationsdetaljer.

Det må være essentielt for en unittest, at
den skrives op mod interfacet, uden at bruge nogen af de underliggende
specialiteter. Ved at du gør dette, opnår du også at du kan genbruge
unittesten, når du skal afprøve en klasse der har samme interface, men
ikke den private metode.

_Hvis_ du ikke kan skrive testen uden den private metode, så skal
klassen(eller dens interface) formentligt omstruktureres.

mvh Jonas

Ulrik Magnusson (03-05-2004)
Kommentar
Fra : Ulrik Magnusson


Dato : 03-05-04 17:09



Kim Schulz wrote:

> hejsa
> Sidder og laver tests til et projekt vha. JUnit. Nu er jeg så stødt
> på det problem at jeg skal teste nogle private metoder.

Din "unit" er klassens ikke-private grænseflade - det er det eneste,
andre klasser kan komme i kontakt med (uden reflection, *host*),
og derfor det eneste, der skal testes. Så sjovt er det heller ikke
at skrive tests

Ulrik Magnusson


Søg
Reklame
Statistik
Spørgsmål : 177459
Tips : 31964
Nyheder : 719565
Indlæg : 6408180
Brugere : 218881

Månedens bedste
Årets bedste
Sidste års bedste