Test-Driven Development and Continuous Integration

Transcription

1 Test-Driven Development and Continuous Integration We have all been there, working all night long on a specific piece of functionality, so happy that we've got something to run finally! We work to merge our code into the repository, pack our stuff, and finally head home. After spending 45 minutes in traffic we get a phone call saying that "Whatever you checked in has somehow corrupted the entire code base!" No one can work now! We need you to come back and correct the issue. If you have been in this scenario then the odds are that you are not using test-driven development, continuous integration, or any form of build automation! The simple idea behind working in a test-driven environment is that you prove that your code works, prior to actually writing the code. Then you write your code and modify your tests to better reflect your code's intent. You refactor over and over till your code does what it is supposed to do. You end up with a solid code and proof that it works in the form of unit tests. Down the road, having this proof in place would be a form of insurance in that it makes sure that your program works as you would expect it to. It is like having a second set of eyes constantly monitoring your code base for you. It is important because if you make a minor change to your code, or more likely, someone else makes a change to your code, your tests should catch it right away. This prompts you to either fix the code that broke your tests or refactor your tests so that they correctly test your new code. Unit Testing 101 Let's begin with unit testing now.

2 Test-Driven Development and Continuous Integration What is a unit test? A unit test can be described as something that tests a specific unit of your program. Generally a unit test would thoroughly test all aspects of the smallest entity in your application throughout every entity in your application. An example of this would be tests for proving that a class works as you would expect it to. A unit test is meant to thoroughly provide coverage for all the various aspects of the unit being tested. It is preferred that these tests are run in an isolated environment. This means that when testing widget A, you want to reduce dependence on widget B as much as possible, or remove all dependencies preferably. What should I test? Now the obvious question that crops up in one's mind is: what should be tested? Let's concentrate on that aspect. Boundaries Boundary checking is a way of testing that our application can handle itself. So if we were using some really fancy math object that say adds two numbers together and produces a result, we would want to make sure that it could add two small numbers without any issue like = 2. Our object should be able to handle that. But let's pretend that our object is not set up to handle really large numbers. We would want to write a test of = knowing that the test would produce an error because it did not support such large numbers. This test is to make sure that our code handles itself with regards to this error. Success and failure As we want to use our test as a way for us to prove that our code works as we would like it to, we would write a test that should pass something like = 2 that would produce true. The second step is to write a test that should fail perhaps (1+ 1) > 2 that would produce false as a result. This has set the bounds for our application proving what works and what doesn't. Functionality So now we know that our code can handle itself under duress. We also know that we have tests built around what we would expect our code to do and not to do. Now you would want to test the details of the specific functionality that your widget should perform (does your data layer connect to the database, does your XML parser parse XML, does your text reader read text, and so on.). [ 2 ]

3 Appendix B Using NUnit While you can write tests around your code without any fancy tools, there are many free frameworks that greatly simplify the testing process. For.NET users the most widely known framework is NUnit. As long as you reference the NUnit DLLs in your project, you have full access to all that is offered by that framework. Installation The installation of NUnit is simple. Go to and download their latest installation file. Once the download is complete, start the installation process and step through all of the screens that are presented. [ 3 ]

4 Test-Driven Development and Continuous Integration Click Next. Select "I accept " and click Next. [ 4 ]

5 Appendix B Leave the defaults and select Next. Now we are ready to install, so click Install. [ 5 ]

6 Test-Driven Development and Continuous Integration Once the installation is done successfully, you will see the following screen, where you click Finish. Now that the installation is complete you will need to navigate to the NUnit directory in the Program Files, or you can go through your start menu. NUnit is not so much a program as a toolset to test your code. It does provide the NUnit GUI that you can run your tests from if you choose not to run the tests from inside Visual Studio (with ReSharper), with a build tool such as NAnt, or on the command line. They also provide a fair amount of example tests for you to take a look at. [ 6 ]

7 Appendix B Test-driven development (TDD) Test-driven development (TDD) could be considered as Test First Development + Refactoring. The easiest way to think of TDD is that it is the blueprint for your functionality. You write tests to define what your program is supposed to do. You then make your code perform according to that specification. As your application grows, you will inevitably refactor your code base continuously. At this point all the tests you built around your code will now act as an early warning system keeping you from running into unseen obstacles below the surface of your application. Another nice side effect to developing this way is that you have expanded the concept of self-documenting code, that is, your tests defining clearly what your application can and can't do, or should and should not do. Tests as a blueprint for your application The basic idea behind how TDD works is that you write a very simple test (prior to writing any actual code) that should fail (as there is no code to test!). You then write the smallest amount of code to make that test pass now. After performing these two tasks you would then refactor your code to the next level and start again. Write another (additional) test that fails again followed by code to make it pass. In most environments, the easiest way to remember this is red light, green light, refactor. Most testing frameworks operate similar to stop lights in that they provide red, green, and yellow icons for feedback! Tests as an early warning system Once you have written your entire application, you should have several tests around each piece of your application the blueprint so to speak. We all know that as a company's focus changes with time. When that happens, the applications that they generally use need to be changed too. To you this means that your application will have to grow and change with the demand of the company. With any change to an application comes the opportunity for bugs. If you have all your tests in place and they are written correctly, a large amount of these buggy introductions should be caught with each build. When they are caught you would then decide if the change was appropriate, in which case the tests should be updated. Or in the case of a bug, the test is correct and the change was not implemented as intended the code needs to be changed. Hence the early warning system. It will save you a lot of time if done right and is well worth the added time to maintain and grow your tests as your application grows. [ 7 ]

8 Test-Driven Development and Continuous Integration Tests as documentation Provided that your tests clearly define what your application can and can't do, you have all the documentation that you should ever need (from a technical point of view) for your system. If there is any question as to what is done where, simply read through your (very descriptive) test method names and you should find your answer. Example Here is a very simple example of a math object where you add two numbers: A test that fails: [TestFixture] public class MathTests { [Test] public void ShouldReturnZeroWithoutInput() { MyMath mm = new MyMath(); Assert.AreEqual(0, mm.add()); } } Now of course, none of this will compile if we don't have a math object to work with! So let's make that real quick. public class MyMath() { public int Add() { return -1; } } [ 8 ]

9 Appendix B As we can see when the said test is run, it will try to do a dry run on the math object and receive a -1 (cheap hack to prove the point), which is not equal in any way to 0! This is our red light. It is hard to see in black and white print whether the bar, icons, and various textual indicators are in a bold red. However, the circular warning icons and messages of failure are a clear indication that our tests did not pass! A test that passes Now, let's modify our code so that the test passes. We will do this by adding two properties for our inputs that the Add method will perform its operations on. Then in the Add method we will evaluate both the properties to see if either of them is 0. public class MyMath() { public int InputOne {get; set;} public int InputTwo {get; set;} public int Add() { return InputOne + InputTwo; } [ 9 ]

10 Test-Driven Development and Continuous Integration After making this small change we now have a test that successfully proves that this math object should return 0 if nothing is specified in the input properties. If anything about this equation should change for some reason, our new test will alert us to the change the next time it is run. As seen in the screenshot, the green doesn't exactly leap off this page, but that is ok. The icons are now check marks and the message is Success! Using NAnt to automate your tests and builds NAnt is more than just a test automation tool. It is an automation tool that is capable of performing pretty much any repetitive task that you might find yourself performing in the software development life cycle. I personally use NAnt to automate the build process for my solutions, testing my applications, deploying the code to the QA and production boxes, team notifications, database updates, and so on. It is very versatile. You should be aware that NAnt comes from the original Ant tool that Java developers have used for so long. The concept has a lot of history. The history and the following of Ant is what has made NAnt such a flexible tool. NAnt is an open source tool that can be found at To get started with this tool, download the installation file from net/project/showfiles.php?group_id= You will see several different files here. If you are interested in looking at the source code for this project, go ahead and download the source file. Otherwise, just download the bin file. [ 10 ]

11 Appendix B At the time of writing this, release 0.86 was in beta. For our discussions I will be using 0.85, which has proven to be quite stable. Installation I plan to cover the basics of getting this tool installed. However, if you find my instructions too brief, you can find a complete (and more importantly up-to-date) list of instructions here: introduction/installation.html. My instructions will be a bit different from what you will find at that URL. I prefer to keep my Nant files directly with my project source code. This way, when a new person is added to the team they can simply get the latest. Moreover, not only will the project files get downloaded, but will also have all the automation tools up and running with no additional configuration. To get started, let's open up our project's trunk directory. In here we will need to create a new folder, which I usually call bin or binaries. For this project, I have gone with the name binaries. Inside your binaries directory, create a NAnt folder. Now open up the file that you downloaded (something like nant-0.85-bin.zip). Then extract all the files you see into the newly-created NAnt folder. Before you forget, commit the new structure and files into your repository! That's it for the installation of NAnt. Now comes the fun stuff! Let's get NAnt configured to work in your development environment. Configuration There are really two primary parts to configuring NAnt to run smoothly configuring NAnt to automate your solutions with a build file and running NAnt from a batch file. NAnt configuration files NAnt is very flexible. It uses a simple XML file, much like any other config file that you see in the.net environment. This XML file ends with a.build extension though. Although you can specify which file NAnt will use, the.build file is what NAnt would normally look for if not specified. [ 11 ]

12 Test-Driven Development and Continuous Integration Let's get started by adding another directory to our trunk folder called build. In the build directory, we will keep our NAnt.build file (the XML configuration file that tells NAnt what to do), our batch files, results from the build process, and so on. Oddly enough, everything to do with the build process! Let's create the build file. I called mine Fisharoo.build. Open that file up and let's add some basic XML so that NAnt can get busy. I posted the entire basic configuration file here so that you can get the 50,000 foot view. I will discuss the basics next. A lot of this should be fairly self-explanatory though. To make your life a lot easier, you should be aware that there is a schema file out there for Visual Studio. This file (nant.xsd) allows Visual Studio's intellisense to help guide you through all the various options of NAnt. Great for the FNG's out there! This file should be located in the initial download that you get for NAnt. Place that file in program files Microsoft Visual Studio X.0 xml schemas and restart Visual Studio. <?xml version="1.0" encoding="utf-8"?> <project name="fisharooweb" default="build" xmlns=" release/0.85/nant.xsd"> <property name="trunk.dir" value="..\"/> <property name="company.name" value="fisharoo"/> <property name="bin.dir" value="..\source\fisharooweb\bin" /> <property name="build.dir" value=""/> <property name="results.dir" value="${build.dir}\results" /> <property name="project.name" value="fisharooweb" /> <property name="version.major" value="1"/> <property name="version.minor" value="0"/> <property name="version.build" value="0"/> <property name="version.revision" value="0"/> <property name="project.fullversion" value="${version.major}.${version.minor}. ${version.build}.${version.revision}" dynamic="true" /> <property name="database.dir" value="..\databases"/> <property name="database.server" value="localhost\sqlexpress"/> <property name="database.name" value="fisharoo"/> <property name="versioneddatabase.dir" value="${database.dir}\versionedcopy"/> <property name="localdatabase.dir" value="${database.dir}\localcopy"/> <property name="currentframework" value="c:\windows\microsoft.net\framework\v3.5"/> <!-- default configuration --> <property name="project.config" value="release" /> [ 12 ]

13 Appendix B <!-- debug release --> <target name="compile"> <echo message="build Directory is ${build.dir}" /> <exec program="${currentframework}\msbuild.exe" commandline="..\source\fisharooweb.sln /t:clean /v:q" workingdir="." /> <exec program="${currentframework}\msbuild.exe" commandline="..\source\fisharooweb.sln /t:rebuild /v:q" workingdir="." /> </target> </project> There are many books and sites out there that do a great job of going over NAnt build files. The first place that you should start is at the NAnt homepage ( I will briefly cover the basics though. The first part of my build files are reserved for property definitions. These are much like any other name-value pair that you have worked with before. It is a good idea to put any value that might need to be changed in a property so that it is easy to get to and adjust down the road. Values you will see in this build file are for items such as directory locations, app names, and so on. The properties can then be referenced with: ${PropertyName} You should be aware that the NAnt executable runs everything from your build file's physical location. This is great. It is one reason I put the NAnt files in the build directory so that it is quick and easy to point to your project's resources! This is the reason why you will see trunk.dir property, which points one directory up the build directory where our build file is run from. Once you work your way through all the property definitions, you will get to the meat and potatoes of NAnt target definitions. Targets are an OOP way of thinking. They compartmentalize a unit of work a task so to speak. Targets can have prerequisite targets (referred to in the depends call out). This means that if Target A depends on Target B, Target B will be executed prior to Target A. This allows you to chain your targets. Once you have a target defined, you can define tasks. You can really do just about anything in your targets. If NAnt or the command line doesn't provide that perfect functionality that you are looking for, you can always create your own widget and tell NAnt how to run your new functionality. In our example, you will see that we output some text to the command line as a message and then execute an MSBuild process on our Fisharoo solution. [ 13 ]

14 Test-Driven Development and Continuous Integration MSBuild is the tool that Microsoft ships, which allows you to build your code via the command line. This means that a developer doesn't really need Visual Studio to develop MS code! If we had tests in our solution, we could also call out those tests and have NAnt run the NUnit tests as part of the build (we don't currently have any tests!) If we did, we would add a section to our NAnt script (inside of a target section) to execute those tests, which looks something like this: <nunit2 failonerror="true" verbose="true"> <formatter type="xml" outputdir="${results.dir}" usefile="true" extension=".xml"/> <formatter type="plain" /> <test assemblyname="${trunk.dir}\source \FisharooCoreTests\bin\Debug\ Fisharoo.FisharooCoreTests.dll" appconfig="${nant::get-basedirectory()}nant.tests.config"/> </nunit2> NAnt and batch files NAnt is a command line tool. This means that you would normally open up the command prompt and manually type commands that you would have NAnt execute for you. LAME? I am specifically using NAnt so that I don't have to do any manual tasks. So I usually automate (batch file) the automation (NAnt build files) to avoid any manual labour. Let's see how this works. In this build directory let's add two more files. The first file we will create is the build.bat file our base batch file. And finally we will create a clicktobuild.bat file, which passes parameters to our build.bat file. You can make as many of these secondary.bat files as you need. You could have a clicktodeploy.bat, a movetoqa.bat, a cleandatabase.bat, and so on. The sky is the limit with helper files! The build.bat file is easy. It is basically some easy command line arguments. It looks something like this:..\binaries\nant\nant.exe -buildfile:fisharoo.build %* This one line is all there is to the build.bat file. It basically states that we will find an instance of the NAnt executable one directory up and inside the binaries nant folder. It then goes on to tell NAnt which build file to use. After that we would [ 14 ]

15 Appendix B normally tell NAnt which target to execute in our build file. In our case though, we specify the percentage sign and an asterisk. The percent and asterisk characters at the end of the line allow us to pass additional arguments into NAnt from another batch file, which allows us to reuse the basic entry points across multiple batch files, allowing us to easily execute different build processes. Let's see this in action! Let's create the next file (if you didn't already). This one will be called clicktobuild.bat. I am guessing you know what this file will do already? Here is an example of what will go in this file: build.bat compile & pause This line of code calls our previous batch file (which we know gets NAnt ready for us). It then passes in the name of the target that we want to execute. In our case, we want to call the compile target. Look at the Fisharoo.build file shown under section NAnt configuration files and you will see that the target has a name attribute, which has a value of compile. Now let's test our setup by clicking on the clicktobuild.bat file. You should see something like this: [ 15 ]

16 Test-Driven Development and Continuous Integration While this is a very basic example of NAnt building some code, I think you get an idea of what NAnt is capable of. Take a look at the build file in this project's completed state for ideas. Now that we have some of our build process automated, what can we do to automate it even more? Read on. Using CruiseControl.NET to automate your automation CruiseControl.NET is an automated continuous integration platform. It allows you to automate the build and test processes on your development server to essentially enforce that your code base stays in good condition at all times. If, for some reason, the code base does find itself in a dirty state, CruiseControl.NET can make everyone aware of it so that its broken state is quickly rectified. Continuous integration (CI) is a concept whereby when a developer checks the code in, it not only merges into the code base as a file overlay but also passes through the build process without errors (and for those in a TDD environment, the new code would also need to pass all the tests). This helps in keeping your code base clean and usable! A team that runs in a CI environment will usually live by the motto "check in often". Preferably don't go home for the day without checking in all your modifications. The further you get from the current code base, the more likely it is that the need for a merger will rear its ugly head. Installation The installation of CruiseControl.NET is fairly easy. It is another open source project that is freely available. You can get it here: thoughtworks.org/display/ccnet/download. Once you have it downloaded to your dev server, let's walk through the installation. [ 16 ]

17 Appendix B Double-click the downloaded installation file. Click Next. [ 17 ]

18 Test-Driven Development and Continuous Integration Click I Agree to continue. I accepted the default installation. This will not only install the CruiseControl.NET integration server, but will also provide you with the Web Dashboard, which allows you to see what is going on with your build processes in a browser. It also installs some samples to look at. Click Next. [ 18 ]

19 Appendix B If you plan to run this server in a production environment, then you will want to install it as a Windows service. This means that the service will be started when the machine is started and should run until the machine is stopped (or the service is manually stopped). If you want to use the dashboard, then allow the install to create a virtual directory for you. Click Next. I accepted the default location. You can also put the installation somewhere else. Then, click Next. [ 19 ]

20 Test-Driven Development and Continuous Integration Just in case you wanted to change the name of what you see in your programs listing, here is your chance to do it! Click Install and watch the magic. You should now see the installer installing various files into your machine. Click Next when the install is completed. Then click Close. Is that it? I wish it were that easy. To start off we need to go into ISS and verify that the version of.net that is being used is 2.0 as the Web Dashboard is a 2.0 application. To do this, go into your start menu program files (or) control panel administrative tools internet information services (IIS) manager. Once that management console opens up, navigate into your default website ccnet (application) and right-click Properties. Then click the ASP.NET tab. Make sure that the ASP.NET version is set to 2.0 and hit OK. [ 20 ]

21 Appendix B Now back in the management console, right-click on the ccnet application again and select permissions. If you don't see the ASP.NET account and the NETWORK SERVICE account, add those as well. You can do that by clicking the Add button. [ 21 ]

22 Test-Driven Development and Continuous Integration Then click the Advanced button. Click the Find Now button to get a list of all the users on your server. Select the ASP. NET and NETWORK SERVICE accounts and click OK. [ 22 ]

23 You should have something as shown in the immediately preceding screenshot. Click OK. Appendix B You should now have the ASP.NET and NETWORK SERVICE accounts in your security listing. For a dev environment you can give these accounts Full Control. If you are setting up your production environment refer to your Network Administrators guidance on setting permissions. Click OK. [ 23 ]

24 Test-Driven Development and Continuous Integration Now right-click on the ccnet application one more time and select the Browse option. If you have configured your server and directory security appropriately, you should now see a window similar to this: Note that while we got the app working, there is still a message stating that the dashboard was unable to connect to the CruiseControl.NET service. Let's fix that! Again, go into the start menu program files / control panel administrative tools Services. In this window, locate the CruiseControl.NET entry. [ 24 ]

25 Appendix B You will notice that the service is installed as manual and is not started. Double-click the CruiseControl.NET entry. Set the startup type to Automatic. Then click the Start button to start the service. Then click OK. We should be good now. You can verify if the service is running correctly or not by going back into IIS and browsing to the ccnet application. You should now see something like this: [ 25 ]

26 Test-Driven Development and Continuous Integration Configuration Now that we have CruiseControl.NET installed and running on your server, let's tell it what we want it to do. In your start menu, navigate to the newly-created CruiseControl.NET entry and click on your CruiseControl.NET Config item. This will open an empty configuration file. This configuration file is stored in the CruiseControl.NET directory in your Program Files directory. Trust me you will be putting a lot of time into the construction of this file over time. So I suggest that you maintain a copy of this file inside your repository probably best kept in the build directory. This way you will get all those wonderful versioning features that your repository offers. Edit the repository version and copy the changes over the server's copy as you need to. Let's start building this file. We will discuss the various sections in a second. For now, here is the file in its entirety: <cruisecontrol> <project name="fisharoo"> <labeller type="defaultlabeller" /> <weburl> <sourcecontrol type="filtered"> <sourcecontrolprovider type="svn" autogetsource="true"> <executable>c:\data\projects\fisharoo\trunk\binaries\subversion\ svn.exe</executable> <trunkurl> trunkurl> <workingdirectory>c:\data\repositories\fisharoo.com</ workingdirectory> <tagonsuccess>false</tagonsuccess> <tagbaseurl>c:\data\projects\fisharoo\tags\</tagbaseurl> <username>[username]</username> <password>[password]</password> </sourcecontrolprovider> [ 26 ]

27 Appendix B <inclusionfilters> <pathfilter> <pattern>**/*.*</pattern> </pathfilter> </inclusionfilters> </sourcecontrol> <tasks> <nant> <executable>c:\data\projects\fisharoo\trunk\binaries\nant\nant. exe</executable> <basedirectory>c:\data\projects\fisharoo\trunk\source\</ basedirectory> <buildargs>-d:svn.executable="c:\data\projects\fisharoo\trunk\ binaries\subversion\svn.exe"</buildargs> <nologo>false</nologo> <buildfile>c:\data\projects\fisharoo\trunk\build\fisharoo. build</buildfile> <targetlist> <target>cruise</target> </targetlist> <buildtimeoutseconds>1200</buildtimeoutseconds> </nant> </tasks> <publishers> <merge> <files> <file>c:\data\projects\fisharoo\trunk\build\results\*.xml</ file> </files> </merge> <xmllogger /> <statistics /> < from="fisharoobuild@fisharoo.com" mailhost="mail.fisharoo.com" includedetails="true"> <users> <user name="andrew Siemer" group="buildmaster" address="asiemer@fisharoo.com"/> <user name="jessica Siemer" group="buildmaster" address="jlsiemer@fisharoo.com"/> <user name="anatoliy Mamalyga" group="buildmaster" address="amamalyga@fisharoo.com"/> <user name="kenny Tongkul" group="buildmaster" address="ktongkul@fisharoo.com"/> [ 27 ]

28 Test-Driven Development and Continuous Integration <user name="arturo Moreno" group="buildmaster" </users> <groups> <group name="buildmaster" notification="always"/> </groups> </ > </publishers> </project> </cruisecontrol> I will walk you through some of these nodes and their attributes, but a better source of information can be found here: public.thoughtworks.org/display/ccnet/project+configur ation+block This is by no means a complete reference on this topic! labeller The labeller is what takes care of your revision numbers, or build numbers. In our case, we are using the defaultlabeller type. This will simply increment the build numbers each time the build occurs. You can configure this section further by adding a prefix, and so on. weburl The weburl is the path to reporting for a project. It is used by CCTray and the Publisher. Sourcecontrol Go to the following link: urce+control+block This section defines how CruiseControl.NET should communicate with your repository. CruiseControl.NET is able to speak with many different types of repositories. I will cover the SVN configuration in a short while. sourcecontrolprovider This section tells CruiseControl.NET which type of repository to communicate with. In our case we will specify SVN. [ 28 ]

29 Appendix B executable This is a path to the SVN executable so that CruiseControl.NET can perform actions on the repository. trunkurl This is the path to the trunk directory of your source code as SVN would communicate with it. It is usually the server name project name trunk. workingdirectory This is the local location that SVN will use to check out the working copy of the repository. tagonsuccess This determines whether or not SVN will tag check-ins upon a successful build. tagbaseurl This is the base URL for your tags in your repository. username/password It is important to specify the username and password for an SVN installation. If you get an "authorization failed" error message, look to these tags (or lack thereof) for the fix to your issue. inclusionfilters This determines which modifications should be included. In our case, we are allowing everything. tasks The tasks section of the config file allows you to specify the functionality for CruiseControl.NET to perform. You can perform all sorts of tasks. For a complete list take a look at: [ 29 ]

30 Test-Driven Development and Continuous Integration nant (task) The nant task is the one we will use most. This allows us to keep most of the functionality in our NAnt build files where we have the most control. executable This tag maintains the path to the NAnt executable so that CruiseControl.NET knows where to go to perform these tasks. basedirectory The basedirectory tag tells NAnt where to go to find the source code for our projects. buildargs The buildargs tag allows us to pass in extra NAnt parameters as though we were running NAnt from the command line. In our case, we are passing in the location of the SVN executable for NAnt to be able to perform SVN related tasks. buildfile This is another NAnt property that needs to be passed so that NAnt has a definition of the tasks to be performed. targetlist/target The targetlist section defines targets that are in your NAnt build file so that NAnt knows which of your targets to act on. In our case, we are telling NAnt to trigger the "cruise" target. From this point, NAnt executes a target as normal, meaning it executes the dependent targets. If you have been following along, you will notice that our NAnt Fisharoo.build file doesn't currently have the "cruise" target. Open your Fisharoo.build file and insert this new target as defined in the following code snippet: <!-- default configuration --> <property name="project.config" value="release" /> <!-- debug release --> <target name="cruise" depends="compile" /> <target name="compile"> <echo message="build Directory is ${build.dir}" /> <exec program="${framework}\msbuild.exe" [ 30 ]

31 Appendix B This target, named "cruise", requires that the "compile" target is executed first. Rather than just calling compile directly from within CruiseControl.NET (which we could have done), we have defined a separate entry point, which will give us greater flexibility down the road. buildtimeoutseconds This specifies how long you are willing to let the entire build process take. If you find that you are going over your acceptable limit, look at reducing the execution time of your unit tests rather than continuing to increase this timeout. Also, you may want to look at removing dependencies on external resources with the use of mocked objects. publishers The publishers section allows CruiseControl.NET to interact with external log files, the log files it generates, and how to send s. Keep in mind that you need to specify all your external application logs (using merged files), CruiseControl.NET xmllogger, and statistics prior to defining your section. The reason being that you won't have access to the data while creating the if the other areas are not yet defined! publishers and merge This tag grouping allows CruiseControl.NET to have access to the output logs of other tools such as NAnt, NUnit, and so on, so that the output can be included in the web control panel or in the ccnet s. files In this section, you can identify the path to the files you want to be used by CruiseControl.NET. publishers and xmllogger The xmllogger is used to create the log files from CruiseControl.NET. Without this tag, your web dashboard will not work! [ 31 ]

32 Test-Driven Development and Continuous Integration publishers and statistics This section allows you to gather some basic statistics about your builds. You will want to define this section after your merge section so that you can pick up some statistics from your other sources. This too should be defined prior to your section so that the gathered statistics can be sent in your notifications. publishers and The section allows you to send out automatic notifications to your development team and management staff. Remember to include this section below all the resources that you might want mentioned in your alerts such as the xmllogger, statistics, and merged files. In this section, you can define the server and the account to be used for sending your as well as the username/password for that account. You can then define the users who will receive notifications and the groups that each user belongs to. After that you can define each group and the frequency at which each group receives notifications. Let's test out the installation and configuration! Now that we have CruiseControl.NET installed and configured on our server, let's see if it works. There are a few ways to check on this: 1. Execute the command line tool located at C:\Program Files\ CruiseControl.NET\server. Then you can check the ccnet.log file for the results. You may want to set the error output level to DEBUG to get a verbose amount of information from the process. 2. Open a command prompt. Navigate to the CruiseControl.NET\server directory.. [ 32 ]

33 3. Then enter ccnet.exe and hit enter. I don't have room to show the entire output of this window, but you should see a bunch of data stream by. Appendix B 4. Once you have this running you can then look into your ccnet.log file. It will have any errors, successes, and so on. [ 33 ]

34 Test-Driven Development and Continuous Integration 5. With the CruiseControl.NET service running, you can also watch the ccnet. log file. In this case, you might want to set the error output level to DEBUG in the ccservice.exe.config. Another place to look for issues is in the web dashboard. Here you can force a build to occur, watch its status, and view its results. Keep in mind this will only work if you have the xmllogger configured in your ccnet.config file to capture all the output! Click the project name. [ 34 ]

35 Appendix B Click the "here" link to view the current status. If you had any errors you could view their details in the "Recent Builds" section. One might look something like this. Given that this is a webpage, you will have to scroll left to read the error. But you do have the entire error message available to you. [ 35 ]

36 Test-Driven Development and Continuous Integration And if your installation and configuration is mostly correct, you will get notifications containing the build status. After performing all this debugging, make sure that you remember to toggle the error output mode in your configuration files away from DEBUG. DEBUG is verbose and outputs everything! This will rapidly bloat your log files. Once your debugging has proven that your CruiseControl.NET installation is working as you would expect it to, you can then make sure that your CruiseControl. NET windows service is running in automatic mode so that each time your box is rebooted, the service comes back up too. Some things to be aware of Some of the issues that I ran into were easily fixed, but might need some explanation here. trunkurl values: I found that the documentation for trunkurl suggested that I use the svn://server/project/trunk notation. This did not work for me. I got an error stating that the connection was refused. To fix this issue I used This fixed the connection refused error but then produced an authentication error. To fix this, I then specified the username/password tags. Depending on how you have your security set up on the server, you may be able to use anonymous authentication. [ 36 ]

37 Appendix B.NET Framework: Please make sure that the.net Framework that you use on your dev machines are installed and configured on your build server. I am using.net 3.5 and C# 3.0. I am also using the latest AJAX, web applications, and so on with these projects. While I had.net 3.5 installed, I found that this did not provide the full framework that my projects required. To fix this, I installed the entire Visual Studio This may not be a requirement by any means to fix an include issue I am sure you can simply install the referenced DLLs and be done with it! I chose to do this so that I could edit the source on my server when I am away from my dev boxes, and fix the issue as well. Web Dashboard: The web dashboard is a.net 2.0 application, which is installed in your default website (in IIS) as the "ccnet" application. Make sure that your security is appropriately configured for your development team to access the site. Also make sure that the.net version that is used by that site is a flavor of.net 2.0. Using CCTray to watch CruiseControl.NET server After you have had CruiseControl.NET installed for a while you will notice that you get a lot of notifications! Some people like this. Others prefer to keep the number of s they receive in the course of a day to a minimum. If you are an minimalist, you should take a look at the CCTray program that comes with CruiseControl.NET. You can either get this program from your CruiseControl.NET installation, or you can get it by navigating to your web dashboard. Once you have the executable downloaded locally, you can get to installing it. [ 37 ]

38 Test-Driven Development and Continuous Integration Installation The installation of CCTray is very simple. Double-click the downloaded install package. Click Next. [ 38 ]

39 Appendix B Click I Agree. Leave all the defaults selected and click Next. [ 39 ]

40 Test-Driven Development and Continuous Integration Click Next. Now we can click Install. [ 40 ]

41 Appendix B The installation process shouldn't take more than a couple of minutes. Once the installation is complete, click Next. [ 41 ]

42 Test-Driven Development and Continuous Integration Click Finish. Once your installation is complete, you should have an icon in your system tray that is a green circle with the letters CC. Adding projects to CCTray Double-click on the CCTray icon in the system tray so that we can connect it to the repository. Click into the File menu and select Settings. [ 42 ]

43 Appendix B Click the Add button. Click the Add Server button. [ 43 ]

44 Test-Driven Development and Continuous Integration Leave the default selection of Connect directly using.net remoting. In the text box, you can either keep the default, that is, localhost, or you can provide your server's name. Click the OK button. You should now see your server and the projects that are installed on that server. In our case, we connected to the server, which has a Fisharoo project. Select the Fisharoo project and click the OK button. [ 44 ]

45 Appendix B Click the OK button. At first you should see the CCTray trying to connect to your server. During this time you will have a gray icon. If everything was installed and configured correctly, you should eventually get the green icon with the last build statistics! Now that you have this program installed, you can double-click on the project name and jump directly to the web dashboard. Now that this program is installed, you can always keep a real time eye on the code base and build. When someone checks the code in, you will see that a build is occurring (indicated by yellow icons) and the activity of building. [ 45 ]

46 Test-Driven Development and Continuous Integration If the build were to fail, the icons would turn red. If the build was in the process of executing while in a broken state, you would have an orange icon stating that the build is still broken. If you find that the visual notifications are not good enough, you can also configure CCTray to give you audible notifications by going to File Settings Audio (tab). Summary We have discussed unit testing and how it will help provide you an early warning system for modifications to your code. Then we went over NUnit, and how it will help you in the creation of your unit tests. Once we had some tests to play with, we discussed NAnt and how it helps automate your building and testing processes. Finally, we discussed CruiseControl.NET and how it can help you finish off the automation aspects, so that any time someone modifies your code base, the building and testing of the code is automatically kicked off in addition to providing various forms of notification to your development team. I am hoping that I overwhelmed you with enough information for this topic to fascinate you. With any luck, the testing and automation bug will get under your skin in the same way that it happened with me. If set up correctly, these tools can really help you maintain a stable code base as well as provide your development team with an additional form of collaboration. [ 46 ]