[NUnit/User-Defined-Attributes] Interface definieren

danielf · Verfasst: Fr 06.09.13 12:36

Hallo Community,

in meiner N-Unit-TestSuite würde ich gerne für wiederkehrende Testabläufe eine Basisklasse mit abstrakten Methoden definieren.

In der Art von

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

abstract class Persistence
{
  Persistency percistency;

  [Test]
  public abstract void Save();

  [Test]
  public abstract void Load();
}

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

class CarPersistence : XmlPersistence
{
  public override void Save()
  {
    Car c = new Car();
    c.Farbe = Color.Blue;
    
    xmlPercistency.Save(c, "C:\car.xml");

    Check("C:\car.xml", "<CAR><FARBE>Blue</FARBE></CAR>");
  }
}

Mein Problem ist nun, dass das Framework die Save-Methode nicht als Test erkennt. Ich muss die Methode in den abgeleiteten Klassen nochmal explizit das [Test] Attribute setzen. Dies finde ich aber sehr nervig ;o

Gibt es ein Lösung wie man die Attribute nicht wieder und wieder setzen muss?

Danke und Gruß
Daniel

Ralf Jansen · Verfasst: Fr 06.09.13 13:01

Zumindest nicht so. Die TestAttribute sind alle nicht als inherited markiert. Und auch wenn die das wären (wenn man es ändern könnte) habe ich Zweifel das der nunit Testrunner das berücksichtigen würde.

Ich denke mal das an einen Test [test] dranschreiben nicht zu aufwendig ist. Ich würde eh sonst in den Methodennamen unterbringen das es ein Test ist

. Denn sonst hätte außer dem ursprünglichen Maintainer jeder Problem das als test zu erkennen. Gerade Save&Load hören sich ja schon sehr funktional an und nicht nach einem Test. Um den Schreibaufwand zu reduzieren helfen vielleicht ein paar auf eure Problemsphäre angepasste Codesnippets.

danielf · Verfasst: Fr 06.09.13 15:09

Danke für die Antwort.

Es geht mir nicht um die Schreibarbeit... eher darum, dass man es nicht vergisst

Eine explizite Benamsung ist nicht notwendig, weil es ein eigene Test-Solution gibt und die Klassen ausschließlich Code für Tests beinhalten.

Code-Snippets halte ich für sehr unflexibel, da Änderungen im Nachhinein keinen Auswirkung auf existierenden Code mehr haben

Mir ist nun eh aufgefallen, dass der Prinzipelle-Workflow in der (abstrakten) Basisklasse geschieht und dementsprechend es nicht notwendig ist die "muss" Tests (Save/Load) in der abgeleiteten zu implementieren. Um das Beispiel von vorhin aufzugreifen:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

abstract class Persistence
{
  Persistency percistency;

  [Test]
  public void Save()
  {
        IPersistenceItem pi = Create();

        percistency.Save(pi, File);

        Validate(pi, File);
  }

  public abstract IPersistenceItem Create();

  public abstract void Validate(IPersistenceItem pi, string file);
}

So ist klar, dass jeder Persistence-Test (leitet von Persistence ab) automatisch das Speichern und Laden testet. Dafür muss er ein Objekt bereitstellen (create) und eine Validate-Methode implementieren, die das erfolgreiche Speichern/Laden überprüft.

Als Test-Entwickler heißt das:
"MyClassPersistence : Persistence<Alt>+<Shift>+<Enter>" und man hat den Rumpf für einen Persistence-Test

Gruß
Daniel

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme