The (Unofficial) ITWorx Technical Architecture Blog

Archive for the ‘Extreme Programming’ Category

Nunit vs MsTest

Posted by archworx on June 10, 2007

After doing a lot some investigations and trying it for ourselves, we came to the conclusion that its better for us to use Nunit instead of using Mstest (the automated unit tests generated by Visual Studio 2005). Of coarse that’s not a general rule, depends of the project and your environment, but in most of our projects, we prefer Nunit for the following reasons

  1. It’s an open standard
  2. Works on all versions of Visual Studio, whereas MsTest only works with Team system or VSTS
  3. Much easier to integrate with Cruise Control (our continuous integration server)
  4. More suited for test driven development cause it allows you to start by coding the tests, whereas the main benefit of MsTest is that it can generates test stubs from your code.

Decide based on your project.


Posted in Continuous Integration, Extreme Programming, Nader | Leave a Comment »

Test Driven Development (TDD)

Posted by archworx on May 27, 2007

One of the basics in eXtreme Programing (XP) is to test any code that might break. In an approach to make life easier, developers wrote tests before writing the actual code!!

“It’s about figuring out what you are trying to do before you run off half-cocked to try to do it. You write a specification that nails down a small aspect of behaviour in a concise, unambiguous, and executable form. It’s that simple. Does that mean you write tests? No. It means you write specifications of what your code will have to do. It means you specify the behaviour of your code ahead of time. But not far ahead of time. In fact, just before you write the code is best because that’s when you have as much information at hand as you will up to that point. Like well done TDD, you work in tiny increments… specifying one small aspect of behaviour at a time, then implementing it.” – Dave Astels

The development cycle in TDD is called Test-Code-Simplify, and it looks like the following:

(“Extreme Programming Applied“, p159)

  1. Write a single test
  2. Compile it. It shouldn’t compile, because you haven’t written the implementation code it calls
  3. Implement just enough code to get the test to compile
  4. Run the test and see it fail
  5. Implement just enough code to get the test to pass
  6. Run the test and see it pass
  7. Refactor for clarity and “once and only once”
  8. Repeat

Posted in El-Geish, Extreme Programming | 1 Comment »

Unit testing

Posted by archworx on November 14, 2006

Do you want to know as soon as your new code breaks some older piece of code, either yours or someone else? I’m sure we all would like that. Well, Extreme programming answer to this is automated unit tests. The idea is that you have a set of classes testing your code; you write a test for each function you have, checking the expected result against actual results. Once you change any part of the code base or add new code, you run the test suite and right there you find out if there is anything broken, the failing tests also show you exactly which part is broken. If all the tests pass, then you know for sure you changes are ready to be integrated with the rest of the system.
The biggest resistance to dedicating any amount of time to unit tests is a fast approaching deadline. But during the life of a project an automated test can save you a hundred times the cost to create it by finding and guarding against bugs. The time it takes to find and fix a bug as you are developing your code is much less than finding it and fixing it after you are done and the system is being tested by the client. The harder the test is to write the more you need it because the greater your savings will be. Discovering all the problems that can occur take time, so to have a complete unit test suite when you need it you must begin creating the tests as you build the code.
Examples of unit test frameworks are NUnit ( for .net and JUnit ( for Java

Posted in Extreme Programming, Nader | Leave a Comment »


Posted by archworx on November 5, 2006

The first practice of extreme programming we are going to discuss is Refactoring. It is the process of changing an existing body of code, changing its internal structure without changing its external behavior. Keeping each refactor (change) small ensures the system is restructured while reducing the chances of things going wrong. Constantly refactoring your code eliminates any duplication and keeps your code-base simple and easy to read and manage. For me it’s always a sign you need to refactor when you find yourself copying and pasting code from one class to another.

There are refactoring tools in most IDEs to make it easier for developers to perform this task; common supported tasks usually include renaming of classes and variables, extracting methods, organizing code and much more. Check your IDE and find out how it can help you refactor and make you life easier and your code cleaner.

Posted in Extreme Programming, Nader | 1 Comment »

Extreme programming

Posted by archworx on November 2, 2006

Extreme programming (XP) is a different approach to software development; it’s been in use with great success by big companies all over the world for the last ten years. The methodology is designed to deliver the customer needs and be flexible enough to adapt to changes in any phase of the life cycle. XP is built on four main concepts; simplicity, developers are encouraged to build the simplest solution that gets the job done. Communication, team members communicate with the customer and each other early and often. Feedback, the code is tested as it’s developed so developers can fix issues as early as possible. Courage, with these concepts in place its easy for developers to change their design and code to react to changing requirements. 

XP practices: 

  1. The Planning Game: The Business team comes up with a list of features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes what is required. The Development team estimates how much of the user stories can be implemented in a given time interval (the iteration). Business team decides which stories to implement in what order.
  2. Start with the smallest useful feature set. Release early and often, adding a few features each time.
  3. Always use the simplest possible design that gets the job done. All you need to do is to meet the requirements as they are right now.
  4. Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Unit Tests are automated tests written by the developers to test functionality as they write it. The customer specifies the acceptance tests to test that the overall system is functioning as specified. When all the acceptance tests pass for a given user story, that story is considered complete.
  5. Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn’t break anything because you have the tests.
  6. Pair Programming: two programmers sitting at one machine write Code. Essentially, all code is reviewed as it is written.
  7. Collective Code Ownership: No single person “owns” a module. A developer is expected to be able to work on any part of the codebase at any time.
  8. Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
  9. Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
  10. Development team has continuous access to a real live customer, that is, someone who will actually be using the system.
  11. Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at a piece of code which developer on the team has touched it.

Of coarse each company and each project should only implement the practices that make sense to them. Even if you don’t follow all the XP rules, you can still take advantage of some of these practices to improve your development methodology considerably. I’ll talk about the practices that I think are essential in future posts.

Posted in Extreme Programming, Nader | 2 Comments »