Testing & Zwei-Zeilen-API Wrapper

[Laurin Stoll]

Hallo zusammen,

Ich habe ein neues Projekt das enorm sicherheitskritisch ist. Deshalb
ist wirklich beinahe jede Zeile peinlich genau getestet. Ich merke
leider immer mehr (siehe mein Post "Aufschrei" von gestern), dass das
bei MS gar nicht so einfach ist.

Nächstes Beispiel die Klasse Application. Ich brauche dort
Application.Run() diese Methode ist statisch.
Mein Controller (sry ist ein VB Projekt) sieht so aus:

''' <summary>
''' Kapselt den Zugriff für die Steuerung des Startbildschirms
''' </summary>
Public Class SplashScreenController
Implements ISplashScreenController

Private m_ViewInstance As ISplashScreenView

Public Sub New()
' Standardkonstruktor - nichts tun
End Sub

Public Sub New(ByVal splashView As ISplashScreenView)
' Konstruktor für testzwecke
Me.m_ViewInstance = splashView
End Sub

Public Sub ShowScreen() Implements
ISplashScreenController.ShowScreen
' Start new thread to show the form
Dim splashThread As New Thread(AddressOf CreateAndShowSplash)
With {.IsBackground = True}
splashThread.TrySetApartmentState(ApartmentState.STA)
splashThread.Start()
End Sub

Public Sub UpdateStatusText(ByVal statusText As String) Implements
ISplashScreenController.UpdateStatusText

If (Me.m_ViewInstance Is Nothing) Then
Throw New InvalidOperationException("Call ShowScreen()
before you call UpdateStatusText()")
End If

Me.m_ViewInstance.UpdateStatusLabel(statusText)
End Sub

Public Sub CloseScreen() Implements
ISplashScreenController.CloseScreen

If (Me.m_ViewInstance Is Nothing) Then
Throw New InvalidOperationException("Call ShowScreen()
before you call CloseScreen()")
End If

Me.m_ViewInstance.CloseForm()
End Sub

Private Sub CreateAndShowSplash()
' Existiert schon eine View? Ist dies der Fall
' ist das meistens ein Mock für einen test
If (Me.m_ViewInstance Is Nothing) Then
Me.m_ViewInstance = New SplashScreen()
End If

' Anzeigen
Application.Run(DirectCast(Me.m_ViewInstance, SplashScreen))
End Sub

End Class

Es ist alles getestet bis auf ShowScreen und demnach
CreateAndShowSplash().

Meine Frage jetzt: Ist das ok? Oder sagt ihr - nein ! das muss auch
getest sein!! Dann wäre sowas wie ein IApplicationAccessor angesagt -
oder? Ich frage mich deshalb weil ich merke, dass man teile einfach
immer mehr nach hinten verschiebt. Man kapselt einfach jedes
untestbare API - aber irgendwann (!!) ist man auf der untersten Ebene
und kann es nicht testen.
Oder ist es dann ok den IApplicationAccessor nicht zu testen?

Wie stur seit ihr da? Was gibts für Möglichkeiten?

Viele Grüsse
Laurin

[Da5id]

Hi,

ich denke, das es recht wenig Sinn macht, alles Basisimplementierungen
mit zutesten.
(->Das läuft dann irgendwann darauf hinaus, dass man
string.IsNullOrEmpty überprüft).

Ich bin vielmehr der Meinung, dass es wesentlich interessanter ist,
die richtigen Dinge zu testen, als 100% Coverage zu haben.

Ein guter Artikel dazu:
http://www.codinghorror.com/blog/archives/001239.html

Gruß

Holger

[Laurin Stoll]

Spannender Artikel :-)

Vielen Dank.

> > Laurin- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Laurin Stoll]

Gerade hatte ich wieder so einen Fall:

public void Insert(User item)
{
this.ObjectContext.AddToUser(item);
}

Testet ihr sowas? Wenn da was fehlschlägt liegt es nicht in meiner
"Unit", d.h. es interessiert mich mal ganz naiv nicht!
Allerdings kann ich sagen: "Doch! ich möchte testen ob der aufruf
stattfindet." Was meint ihr? Testet ihr sowas mit einem unit Test?

glg

> > - Zitierten Text anzeigen -- Zitierten Text ausblenden -

[Holger]

Hi Laurin,

Du kannst z.B. überprüfen, ob der Aufruf auf
this.ObjectContext.AddToUser korrekt ausgeführt wird. Desweiteren
könntest Du überprüfen ob nach dem Aufruf der User im ObjectContext
verfügbar ist.
->Ich schätze Du arbeitest mit Mocking?

Gruß

Holger

[Laurin Stoll]

Hallo Holger,

Ja, dass ich das testen kann weiss ich. Ja ich arbeite mit Mocking.
Ich frage mich nur ob das auch sinnig ist zu testen. Schliesslich gehe
ich davon aus, dass AddToUser() fehlerfrei läuft und nur zu testen ob
dieser Aufruf stattfindet finde ich quasi ein Verstoss gegen DRY. Oder
nicht?

[Holger]

Hi Laurin,

nein, ich denke nicht, dass die Überprüfung, ob die Methode aufgerufen
wird, gegen das DRY Prinzip verstößt.
Auf der einen Seite ist keines der Prinzipien (KISS, SRP, etc.) in
Stein gemeißelt, auf der anderen halte ich die Überprüfung des Codes
nicht für den Teil der Implementierung, auf die das DRY Prinzip zielt.

Wenn man genau hinschaut, wirst Du gegen das Prinzip nicht verstoßen,
nur weil Du überprüfst, ob der Aufruf stattgefunden hat. Oder tust Du
das sonst noch irgendwo?

Gruß

Holger

P.S.: Warum gehst Du davon aus, dass AddToUser() fehlerfrei
funktioniert?

[Laurin Stoll]

Na ich rede von Unit Tests. Und der ObjectContext ist nunmal nicht
meine Unit. Ich nehme einfach mal naiv an, dass der funktioniert. Und
da der ObjectContext keine gescheite Abstraktion hat - kann ich nur
direkt gegen die DB testen. das geht für mich dann mehr Richtung
Integrationstest. Und für mich scheint dieser Test ob der Aufruf
wirklich getätigt wird (mock aufbauen asserten ob der call
stattfindet) einfach oversized für einen einzeiler. Das das ganze dann
mit einem Integrationstest noch getestet werden soll steht natürlich
ausser frage. Aber da gehts ja dann auch ab gegen die db.

Grüsse
Laurin

[Holger]

Hi Laurin,

da sind wir wieder bei der Gretchenfrage, ob es sinnvoll ist, 100%
Coverage zu haben.
Bei einem Einzeiler muß man sich wirklich fragen, was das größere
Problem darstellt, das
Schreiben und Pflegen der Tests oder die Möglichkeit, dass dieser
Einzeiler nicht funktioniert.

:-)

Gruß

Holger