Because I'm interested in what people say about WatiN I look around at Technorati (http://technorati.com) from time to time. From there I picked up this great article about Agile development and WatiN. I think Rainer and Karin has put to gather a very nice article! Thanks guys! Have a look at how they use Visual Studio 2008, Linq-To-Sql and WatiN at http://www.software-architects.com/TechnicalArticles/TestDrivenDevelopment/tabid/83/language/en-US/Default.aspx
Strange thing is that I implemented somewhat in the same way our example application for our presentation at Agile Egypt. I don't have any article going with it but if you are interested you can download the example code (http://www.agileegypt.com/presentations_March2008/Agile%20Lab%20code.zip) and our presentation (http://www.agileegypt.com/presentations_March2008/Agile%20Lab.pdf) from the agile egypt site (www.AgileEgypt.com).
The purpose of our presentation was to show people a small agile development project using Test Driven/First Development. So we went through the creation of a web site to sign up for a course:
Iteration 0: Setting up source control and continues integration
Iteration 1: A very basic implementation of a list of courses
Iteration 2: TDDing our way through our tasks for creating a sign up page for a course.
In our presentation we used :
- Visual Studio 2008 with Linq. I love the new Linq syntax and the extensions methods it adds to types implementing IEnumerable.
- ASP.Net MVC Toolkit (http://www.asp.net/downloads/3.5-extensions/). After playing with it a bit I knew immediately that I didn't want to go back developing in webforms..... But reality is different.
- WatiN (http://watin.sourceforge.net). Need I say more :-)
- NUnit 2.4 (http://www.nunit.org/). Because we are familiar with it and (still) like it. Especially the Assert.That() syntax is sweet.
- LightORM (http://www.codeproject.com/KB/database/LightORMLibrary.aspx), an open source API to persists your classes to a database. We choose this because we wanted to show the audience that it is possible to start without having to setup a database before you start coding, the Test Driven Development way of doing things (yes we went very pure on this).
- NAnt (http://nant.sourceforge.net/). Mainly because we aren't familiar with MS Build and NAnt has served us great in the past and probably will in the future.
- Hudson (https://hudson.dev.java.net/) for continues integration. It is a JAVA application and really simple to setup for continues integration. Just kick of the build.bat file from Hudson, which will kick of the NAnt build and you have your CI running.
- And last but not least we used SubVersion (http://subversion.tigris.org/) and TortoiseSVN (http://tortoisesvn.tigris.org/) as our source control system.
Have a look at the code and let my know what you think of it. And don't forget to install the ASP.NET MVC Toolkit release from last December before firing up the code in Visual Studio. There is also a build.bat file to kick off the (automated) build.
4 reacties:
I just read Rainer and Karin post.
It is really interesting.
But do you think that for web testing TDD is really better that simply Test After?
Frederic Torres
www.InCisif.net
Web Testing with C# or VB.NET
In my opinion both can be applied. If you are a TDD guy or gal, it is no problem to create your tests first for the UI and than create the HTML or aspx to satisfy the test. It was an interesting experience doing it for the demo. I'm sure this influenced the design of the demo app somewhat.
This way of working is helped if you have some user stories with scenarios (behavior driven development). Testing these scenarios through the UI makes most sense. So why not start with these (acceptance) tests first before creating the plumbing behind the UI.
But from what I have encountered up to now is most people use TAD (test after development). Mostly because people create UI tests for existing projects. An other reason is that UI tests are mostly developed by others then the developers of the UI.
Just my 2 cents.
Jeroen
I can't think of much reasons why testing after would be better then testing before.
When you test after, most of the times it's alot harder to create the tests, and often times tests are completely left out because of this. This ofcourse results in uncovered application code which is unwanted.
By the way, very nice presentation.
Een reactie posten