ACHTUNG - NEUES BLOG

Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen EintrÃ¤gen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.

.NET BlogBook Ausgabe 6

14.04.08 - Entwicklung, Diskussionen, Patterns, Software Testing, Projektmgmt., Qualitätsmgmt., .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder

Ab sofort steht die 6. Ausgabe des .NET BlogBooks zur Verfügung. Insgesamt stehen nun fast 330 Seiten an puren Informationen und Praxiswissen zur Verfügung.

Noch dazu wurden einige Anregungen aufgegriffen. Es gibt ein neues Cover (ein herzliches Dankeschön an 69° media solutions). Ebenfalls wurden unnötige dunkle Stellen entfernt, die beim Ausdrucken maximal Toner verbrauchen, sonst jedoch keinerlei Wirkung erzielen.

Hauptsächlich wurde das BlogBook um Wissen rund um die Windows Presentation Foundation erweitert, aber auch andere Punkte kamen hinzu. Ein Blick lohnt sich allemal.

Weitere Informationen sind auf der Homepage unter http://www.dotnet-blogbook.com zu finden.

Für Anregungen, Wünsche und (konstruktive) Kritik haben wir natürlich weiterhin ein offenes Ohr.

6 Kommentare - 1357 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

NAnt: Solution aus Visual SourceSafe aktualisieren

27.09.07 - Entwicklung, Software Testing, Qualitätsmgmt., .NET, Allerlei
Beitrag von Norbert Eder

Zu NAnt gibt es ja das Zusatzpaket NAntContrib welches den Task vssget zur Verfügung stellt. Dadurch kann die letzte Version aus dem SourceSafe geladen werden.

Blöderweise funktioniert dies nur bei Visual SourceSafe 6.0d, jedoch nicht mehr mit SourceSafe 2005. Der Grund hierfür liegt darin, dass nicht doe Commandline-Funktionalität verwendet wird, sondern die Visual Studio Integrations-Schnittstelle.

Grundsätzlich wäre das nicht weiter schlimm, würde eine Side-by-Side-Installation der Versionen 6.0d und 2005 möglich sein. Ist es aber nicht. Die zuletzt installierte Version setzt den verwendeten Provider. Ergo auch keine wirkliche Lösung.

Abhilfe schafft hier:

1. NAntContrib selbst anpassen und die notwendigen Änderungen durchführen (denn das Projekt scheint auch nicht mehr wirklich aktiv zu sein)

2. Visual SourceSave 6.0d installieren und nicht 2005 verwenden

3. Einen alternativen Weg finden, beispielsweise diesen Vorgang über einen MSBuild-Task abzubilden, wobei hier dann insgesamt zwei Build-Werkzeuge ins Spiel kommen - auch nicht optimal.

Wird der komplette Prozess auf einem eigenen Server ausgeführt kann dieser ja entsprechend konfiguriert werden. Darin liegt nicht das Problem. Vielmehr ist es nervig, wenn auf der lokalen Maschine Tests durchgeführt werden müssen (Debugging etc.). Klar kann hier eine VM verwendet werden, ist aber vielleicht auch wie mit Bomben auf Tauben schießen.

Hat hier jemand vielleicht einen entsprechenden Tipp parat um NAntContrib auch mit SourceSafe 2005 zum Laufen zu bewegen, speziell den vssget-Task?

Zusätzlich gehe ich einmal davon aus, dass NAntContrib in Verbindung mit dem Team System wohl auch eher ein Problem sein wird.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Kostenlose Code Coverage Tools

27.01.07 - Entwicklung, Diskussionen, Software Testing
Beitrag von Norbert Eder

Was ist Code Coverage?

Die Code Coverage Analyse wird zusammen mit Unit Tests eingesetzt. Durch sie wird überprüft, welcher Anteil des Sourcecodes durch Tests abgedeckt wird. Dadurch kann weiters festgestellt werden, welche Bereiche nicht abgedeckt sind und hat so die Möglichkeit, dafür entsprechende Unit Tests zu bilden. Insgesamt wird durch den Einsatz der Code Coverage Analyse die Qualität der Unit Tests verbessert.

Kostenlose Code Coverage Tools für .NET?

Kommerzielle Produkte zu diesem Thema gibt es einige, jedoch auch kostenlose Tools sind verfügbar.

NCover ist eines dieser kostenlosen Tools und steht aktuell in der Version 1.5.5 beta zur Verfügung, welche jedoch nur mit dem .NET Framework 2.0 zusammenarbeitet und nicht abwärtskompatibel ist. Dazu muss zu einer älteren Version gegriffen werden. Für eine komfortablere Auswertung der Berichte bietet sich der kostenlose NCoverExplorer an.

Eine weitere Variante stellt PartCover dar. PartCover unterscheidet sich in einigen Bereichen von NCover, leistet jedoch auch gute Dienste.

Lohnt sich der Einsatz?

Egal ob nun ein kostenloses Code Coverage Tool oder ein kommerzielles eingesetzt wird, insgesamt wird die Qualität der Unit Tests und somit der gesamten Software erhöht. Daher: Sehr empfehlenswert.

1 Kommentar - 216 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

ReSharper UnitRun: kostenloser Testdriven.NET Gegenspieler

12.12.06 - .NET, Base Framework, Software Testing, Software Testing
Beitrag von Norbert Eder

	Von JetBrains gibt es ein kostenloses Visual Studio Add-In mit dem Unit Tests ausgeführt werden können: ReSharper TestRun [1]. Unterstützt werden folgende Testing-Frameworks: - NUnit - csUnit Ein näherer Blick auf dieses Tool lohnt sich auf jeden Fall. [1] UnitRun Homepage via Thomas.
	2 Kommentare - 1258 mal angesehen \| 0 Trackbacks \| Permalink \| Trackback-URL

Das Übel Software-Testing

20.10.06 - Entwicklung, Software Testing
Beitrag von Norbert Eder

Gestern hatte ich ein längeres Gespräch mit einem befreundeten Entwickler. Basis der Diskussion war das Thema Software-Testing in allen Formen, Varianten und warum die Akzeptanz so gering ausfällt.

Fakt ist (zumindest laut meiner persönlichen Erfahrung), dass nur sehr wenige Firmen Software wirklich testen. Damit meine ich nun weniger, das rein zufällige Finden von offensichtlichen Bugs durch unkontrolliertes - an Zuckungen erinnerndes - Herumklicken auf der GUI, sondern vielmehr der Einsatz von einschlägigen Hilfsmitteln á Unit-Tests und Co.

Wenn ich nun kommuniziere, dass es am zusätzlichen Aufwand liegt, dann wiederhole ich mich, denn dieser dürfte es anscheinend nicht sein. Vielmehr daran, dass viele Entwickler nur dann Spass am Programmieren haben, wenn Neues geschaffen werden kann. Beim Schreiben von Tests muss jedoch bereits entwickeltes geprüft werden (in vielen Fällen), was einer Wiederholung gleich kommt. Um es auf den Punkt zu bringen: es ist einfach fad. Daher wird dieser wichtige Schritt einfach nicht durchgeführt.

Das Resultat? Nun, wer würde sich ein Auto kaufen, welches jedes Mal auf der Autobahn abstirbt, weil der Motor aufgrund der andauernden Belastung überhitzt, also quasi einen Überlauf verursacht. Oder man stelle sich vor, dass das Aufblendlicht nicht funktioniert, weil der Kontakt zur Birne fehlt, was vergleichbar mit einer Null-Reference-Exception wäre. Viele viele Beispiele gäbe es an dieser Stelle. Grundsätzlich möchte jeder ein voll funktionstüchtiges Auto. Genauso verhält es sich mit Software. Wenn andere Branchen so fehlerbestückte Produkte ausliefern würden, wie es Software-Branche tut, könnten wir vermutlich mit keinem Gerät bzw. keinem Produkt tatsächlich etwas anfangen. Das stimmt sehr nachdenklich.

In diesem Sinne wünsche ich einen guten Start ins Wochenende und auf dass es in Zukunft nicht auch notwendig ist, die Software zum Service zu bringen oder gar jährlich ein Pickerl (TÜV) machen zu lassen ...

5 Kommentare - 1115 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Grundlagen: White Box Tests

06.08.06 - Software Testing
Beitrag von Norbert Eder

Bei den White Box Tests wird im Gegensatz zu den Black Box Tests die Implementierung einer Komponente getestet. Dies bedeutet, dass vor dem Entwickeln des Tests ein Blick auf den Sourcecode durchaus erlaubt ist.

Ziel der White Box Tests ist es, dass bezüglich des Sourcecodes bestimmte Hinlänglichkeitskriterien erfüllt werden. Eine komplette Fehlerfreiheit kann durch diese Tests nicht sichergestellt werden. Eine Kombination mit anderen Test-Methoden ist anzuraten.

Weitere Methoden der Softwaretests:
* Black Box Tests
* Grey Box Tests

Kommentar hinzufügen - 17 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Grundlagen: Black Box Tests

06.08.06 - Software Testing
Beitrag von Norbert Eder

Die Black-Box-Tests gehören dem allgemeinen Softwaretests an und stellen eine Methode dar, Tests für Komponenten zu entwickeln, die noch nicht erstellt wurden. Für die einzelnen Tests wird die Spezifikation der Methoden, Klassen etc. herangezogen, jedoch nicht die dahinterliegende Implementierung (funktionsorientiertes Testen).

Das Ziel besteht darin, die Software hinsichtlich der Spezifikationen zu prüfen. Diese geben Schnittstellen, Definitionen und Ergebnisse vor, welche von den einzelnen Komponenten einzuhalten sind und entsprechend geprüft werden müssen.

Ein Black-Box-Test kann jedoch sehr aufwändig sein und birgt auch ein weiteres Problem in sich:
In der Softwareentwicklung werden Komponenten ständig weiter entwickelt. Daraus ergeben sich neue Funktionalitäten, die ebenfalls getestet werden müssen. Diese Tests sind jedoch in den Black-Box-Tests nicht enthalten, da diese bereits vor der Komponente entwickelt werden. Erfolgreiche Testläufe bedeuten daher jedoch nicht zwangsweise, dass die gesamte Funktionalität der Komponente zu einem späteren Zeitpunkt getestet wurde, sondern lediglich die ursprüngliche Spezifikation.

Zusätzlich gibt es noch weitere Verfahren:
* Grey Box Test
* White Box Test

Kommentar hinzufügen - 14 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Grundlagen: Testgetriebene Entwicklung oder auch test-driven Development

06.08.06 - Software Testing
Beitrag von Norbert Eder

Die testgetriebene Entwicklung kommt aus dem Bereich der agilen Softwareentwicklung und legt fest, dass Software-Tests vor der Entwicklung der zu testenden Komponenten erstellt werden. Zur Verwendung kommen sogenannte Grey-Box-Tests. Diese vereinen die Vorteile der White-Box-Tests [1] und der Black-Box-Tests [2] in sich:

1. Die Software-Tests werden vom Entwickler der Komponente selbst geschrieben (White-Box-Test)
2. Der Test wird ohne Kenntnis der Komponente (da diese ja noch nicht entwickelt ist) erstellt (Black-Box-Test)

Der Vorteil dieser Variante liegt darin, dass nicht um Fehler "herumgetestet" wird. D.h. die Tests werden nicht der Komponente angepasst, sondern die Komponente muss so funktionieren, wie dies im Test festgelegt wurde.

Bei dieser Art der Tests empfiehlt es sich jedoch eine hohe Disziplin an den Tag zu legen und zusätzliche Arbeitsweisen aus der agilen Softwareentwicklung zu nutzen. Zusätzlich sollte nicht auf Black-Box-Tests verzichtet werden.

[1] White Box Tests
[2] Black Box Tests

Kommentar hinzufügen - 10 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Unit-Tests und Aufwand

16.02.06 - Entwicklung, Software Testing
Beitrag von Norbert Eder

Danke für die vielen Rückmeldungen, die ich vor allem in Form von Emails erhalten habe. Dabei stand fast immer die Frage nach dem Aufwand im Vordergrund.

Zu diesem Thema kann ich folgendes sagen/behaupten:

Natürlich verursacht das Erstellen von Unit-Tests einen entsprechenden Aufwand, da jede Methode in allen erdenklichen Varianten getestet werden soll. Sinnvollerweise wird der Unit-Tests parallel zur zu testenden Klasse entwickelt. Dadurch erhöht sich zwar der Aufwand für die Entwicklung von Klassen, man bedenke aber das große ABER:

Durch die ständigen Test-Durchläufe kristallisieren sich sehr schnell Fehler heraus bzw. wo es nach einer durchgeführten Änderung ein wenig zwickt. Sollte dann doch einmal ein Fehler durchrutschen, kann mit Hilfe der Unit-Tests dieser recht schnell nachvollzogen bzw. überhaupt gefunden werden. Das erspart sehr viel Zeit. Vermutlich mehr, als man sich durch das Nichtschreiben von Unit-Tests sparen würde.

Jeder Leser kann sich nun selbst ein Bild davon machen. Einfach die durchschnittliche Anzahl der Bugs heranziehen und kurz darüber nachdenken, wie schwer so manche davon zu finden sind. Viele davon wären mit Unit-Tests erst gar nicht zustande gekommen.

Ich hoffe dieser Beitrag regt zum Nachdenken und Nachrechnen an und liefert so für jeden von Euch ein Ergebnis bezgl. der Sinnhaftigkeit von Unit-Tests.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Zurück