als RSS-Feed abonnieren
Hundezuechter
McKinsey
XML-Ferientermine
xml-ferientermine
Go-Spiel-bei-DGS
Projektarbeit
Wohnungssuche
Bewerbungen
Ruby-in-Second-Life
Clatronic-CTV731-bei-Saturn
T_Shirts_Mousepads
Singleboersenvergleich
TimeSystem
Katzen
katzen
Arbeitsamt_I
Klick
2007-01-21
2007-01-19
Leapc
iMacros-to-Watir-Konverter
ASP
Ruby-Stocks
National-Geograpic
Google-Kalender
XML-Ruby
XMLTV
css
scribus
ruby-links
c-sharp
videos-fuer-psp-konvertieren
tchibo-infoglobe
uuencode-ruby
linux-phone-neo-1973
mx600-mouse
ruby-mechanize-https
ncurses
internetcafes
corba
ruby-einladung
ruby-setup
ruby-xml
watir
find-ersatz-in-ruby
ruby-priority-queue
gem-needle
gem-dependency
index
DotNetTests
TDD
Gadgets
RSS
Geocaching
2006-10-22_CSS_hier
2006-10-22-zaurus
2006-10-22
2006-10-22_Mono_und_Linux


vom: 2006-10-23 07:41

DotNetTests

Wikipedia erklärt hier, warum Komponenten-Test durchgeführt werden. Speziell zu .NET wird dort auf folgende Fundstellen verwiesen: Wikipedia-NUnit (ist dies das einzige, was es für C# und .NET gibt?).

Testdriven.NET dort, scheint ein ganz interessanter Ansatz zu sein, muß ich für meine Arbeit einmal ausprobieren. Allerdings ist dies eine kommerzielle Version und ich weiß nicht, ob meine Firma bereit wäre, eine Lizenz dafür zu kaufen.

The Death of NUnit Revisited – Will it be Fire?

Darüber hinaus kann man .NET-Anwendungen, solange sie über einen herkömmlichn Browser aufgerufen natürlich auch mit meinen Test-Funktionn AWT bzw. dem Ruby-Gem mechanize testen. Hiermit kann aber nur getestet werden, was an der Oberfläche sichtbar ist. Leider kommt bei aspx-Seiten ein unangenehmer Bug von mechanize (bzw. dem darunter liegenden hpricot) des öfteren zum Tragen. Dieser Bug führt dazu, daß bei bestimmten Seiten einfach die Bearbeitung mit der Fehlermldung “OUT OF BUFFER SPACE” abgebrochen wird (ohne Exception, die man abfangen könnte).

Generell halte ich persönlich sehr viel von Test Driven Development. Ich finde es sehr viel einfacher Klassen bzw. Programme zu entwickeln, wenn ich zuerst die Tests dafür schreibe und mir damit selbst klar mache, bzw. beschreibe, was ich von meinem Code erwarte. Dies führt zum einen dazu, daß ich genau dies entwickle und zum anderen nichts schreibe, was unnütz oder im Moment nicht benötigt wird. Die Funktionalität ist dann erreicht, wenn alle meine Testfälle korrekt durchlaufen. Siehe auch: TDD

Kontakt: Thomas Preymesser
Prinzenallee 36
13359 Berlin
Telefon: 030 - 49 78 37 06
mobile: 0172-8111959
eMail: thopre@gmail.com