[Løst] JUnit som ikke fungerer

[jevli]

Hei

 

Jeg sitter med en oppgave, hvor vi skal benytte JUnit (total bullshit slik jeg ser det, men den diskusjonen får vi spare oss idag).

 

Jeg har en klasse med navn Person, hvor man lager personer med fornavn, etternavn, fødselsdato osv osv. Så auto-generer jeg en test-klasse i Eclipse, for å teste to av metodene; setFirstName() og setSurname().

 

Har prøvd å lese meg opp på hvordan disse testene skal fungere, og trodde da jeg hadde skjønt tegninga? Eller kan noen av dere se hva som er feil med følgende test-metode?

 

@Test
public void testSetFirstname() {
 Person person = new Person("A","B");
 person.setFirstname("John");
 assertEquals("Firstname must be","John",person.getFirstname());
 fail("Not yet implemented");
}

[_Xorcist]

Hei

 

Jeg sitter med en oppgave, hvor vi skal benytte JUnit (total bullshit slik jeg ser det, men den diskusjonen får vi spare oss idag).

 

Jeg har en klasse med navn Person, hvor man lager personer med fornavn, etternavn, fødselsdato osv osv. Så auto-generer jeg en test-klasse i Eclipse, for å teste to av metodene; setFirstName() og setSurname().

 

Har prøvd å lese meg opp på hvordan disse testene skal fungere, og trodde da jeg hadde skjønt tegninga? Eller kan noen av dere se hva som er feil med følgende test-metode?

 

@Test
public void testSetFirstname() {
 Person person = new Person("A","B");
 person.setFirstname("John");
 assertEquals("Firstname must be","John",person.getFirstname());
 fail("Not yet implemented");
}

 

Det er overhodet ikke bullshit med JUnit og hyggelig at dere får kjennskap til verktøy som er et absolutt krav å ha kjennskap til hvis du skal drive med Java profesjonelt. Eksempelet du viser er selvsagt litt fjollete å teste, men å bli vant til å skrive tester er uansett ålreit. Når det gjelder å autogenerere tester så er ikke Eclipse så god til det.

 

Med JUnit4 trenger ikke metodenavnet å prefixes med "test". Fordi du kaller fail() til slutt failer alltid testen din. Det er egentlig aldri noen god grunn til å bruke fail() som jeg kan komme på.

 

Her er eksempel på hvordan testen kan se ut hvis du bruker penere assert matchere. Disse er lettere å lese og gir ofte bedre feilmeldinger hvis de feiler.

 

import org.junit.Test;


import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

@Test
public void canSetAndGetFirstName() {
Person person = new Person("A", "B");
person.setFirstName("John");
assertThat(person.getFirstName(), is(equalTo("John")));
}

Endret 18. mars 2013 av _Xorcist

[jevli]

Det er overhodet ikke bullshit med JUnit og hyggelig at dere får kjennskap til verktøy som er et absolutt krav å ha kjennskap til hvis du skal drive med Java profesjonelt. Eksempelet du viser er selvsagt litt fjollete å teste, men å bli vant til å skrive tester er uansett ålreit. Når det gjelder å autogenerere tester så er ikke Eclipse så god til det.

 

Med JUnit4 trenger ikke metodenavnet å prefixes med "test". Fordi du kaller fail() til slutt failer alltid testen din. Det er egentlig aldri noen god grunn til å bruke fail() som jeg kan komme på.

 

Her er eksempel på hvordan testen kan se ut hvis du bruker penere assert matchere. Disse er lettere å lese og gir ofte bedre feilmeldinger hvis de feiler.

 

import org.junit.Test;


import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

@Test
public void canSetAndGetFirstName() {
Person person = new Person("A", "B");
person.setFirstName("John");
assertThat(person.getFirstName(), is(equalTo("John")));
}

 

Hei og takk for svar! Du har nok rett om JUnit, jeg ser vel nytten etterhvert.

[GeirGrusom]

Det er egentlig aldri noen god grunn til å bruke fail() som jeg kan komme på.

En unit-test som er forventet å gi en exception:

 

try
{
 TheFoo.foo();
}
catch(ExpectedExcption)
{
 return;
}
catch
{
 Assert.fail("Unexpected exception.");
}
Assert.fail("foo() should have thrown an exception, but didn't.");

 

Dette kan derimot istedet skrives med expected argumentet til Test-attributten, men i noen tilfeller er det kanskje ønskelig å undersøke exception nærmere.

 

Eneste jeg egentlig kan forestille meg.

Endret 21. mars 2013 av GeirGrusom

[_Xorcist]

En unit-test som er forventet å gi en exception:

 

try
{
 TheFoo.foo();
}
catch(ExpectedExcption)
{
 return;
}
catch
{
 Assert.fail("Unexpected exception.");
}
Assert.fail("foo() should have thrown an exception, but didn't.");

 

Dette kan derimot istedet skrives med expected argumentet til Test-attributten, men i noen tilfeller er det kanskje ønskelig å undersøke exception nærmere.

 

Eneste jeg egentlig kan forestille meg.

 

Ja, det vil være naturlig å bruke expected-feltet på @Test. Hvis man virkelig har behov for å asserte på noe mer enn hvilken type exception det er så er det kanskje mest naturlig å asserte på innholdet i exception slik at det feiler hvis innholdet ikke matcher fremfor de konstruksjonene hvor man eksplisitt kaller fail().