W@rfi Blog

In principle TDD says “write test before you program” but it has a little more insight like:
•    It pressurizes the developer to think about the module he is to program even before he writes it.
•    Indirectly, it introduces a level of design before we even write something, which is of course very good.
•    Using automated testing, we are awared at all the times where does our code stand at any the times.

Red / Green Refactor

• Red factor says, write a test that fails.
• Green says write code to make the test pass.
• Refactor says improve the design so that code works as well as test passes.

Frameworks available for unit tests automation are Junit, Nunit, Microsoft Test Environment. For .Net environment NUnit and Microsoft Test System both could be used. We need to look at the pros and cons of both which will be presented in the sections below.

Tips for writing unit test

• Tests we write should just test the functionality, we should not start programming in our tests making them more complex and useless as well.
• All tests should be independent in themselves.
• Prepare and destroy test data on start and end of the test

Comparison of NUnit and Microsoft Team System
In the following a comparison has been presented between NUnit and MS Team System.

admin .Net microsoft, nunit, red green refactor, tdd, team system, test driven development

You must be hearing and working as well on all the buzz about build automation, minimizing the chances for manual interaction by CC personnel. Yet it is a challenge to keep build scripts updated at all the times. I will talk about two tools that I have used for build automation and will share my experiences. I liked two aspects regarding build automation. These are:

• Continuous Integration
• Automated Build Generation

When I say continuous integration, I mean:

• Monitor changes in the repository
• Publish the results via web and email

When I say build automation, I mean:

• Get source code from the repository
• Build the complete application package
• Executing unit tests
• Coding standards validation using FxCop or some other tool
• Creating documentation using NDoc or some other tool

My choice is to use CruiseControl.Net for continuous integration and NAnt for build automation. I feel more power & flexibility using NAnt. I am more comfortable using its tags. Its your choice you may make use of CruiseControl.Net tags if you want. In the following I would show you sample scripts for both of these tools to work hand in hand.

CruiseControl.Net (Continuous Integration)

This tool as I mentioned is used for Continuous Integration. Once the repositories are in place, we can make use of this tool so that on every change in the repository OR in a timely manner, this process could be started off.  You can download this tool from http://ccnet.thoughtworks.com.

It is purely xml based, you just need to configure its configuration file named ccnet.config. In the following, you will find a sample script which will contain tags for the repository to monitor, call NAnt & publish results on web and email.

<cruisecontrol>
<project name=”ProjectName”>

<sourcecontrol type=”vss” autoGetSource=”true”>
<ssdir>\\YourServer\vss\</ssdir>
<executable>\\YourServer\vss\win32\SS.EXE</executable>
<project>$/ProjectName</project>
<username>YourUsername</username>
<password></password>
</sourcecontrol>

<!– Changed to correct url –>
<webURL>http://localhost/ccnet</webURL>
<schedule type=”schedule” sleepSeconds=”60″/>
<build type=”nant”>
<executable>DrivePath\nant\bin\NAnt.exe</executable>
<baseDirectory>DrivePath:\projects\ProjectDir\</baseDirectory>
<buildFile>MyBuild.build</buildFile>
<targetList>
<target>build</target>
</targetList>
<buildTimeoutSeconds>300</buildTimeoutSeconds>
</build>
<modificationDelaySeconds>10</modificationDelaySeconds>
</project>
</cruisecontrol>

The above is a sample script file that contains source control tag for VSS. Repository mentioned in this tag will be monitored for any changes. Then in the build type tag, NAnt has been invoked using build tag. NAnt will automated build generation. When cruise control is being invoked, this script gets executed.

Let’s look at NAnt now.

NAnt (Build Automation)

The above script will invoke NAnt whenever there is a change in the repository. NAnt is also open source, which is an equivalent for .Net like Ant for Java. Using NAnt we will generate the complete build and related processes. It could be downloaded from http://nant.sourceforge.net/.

Along with NAnt you will also need NAntContrib, its a contribution written over NAnt to provide you with some additional tags. NAntContrib can be downloaded from http://nantcontrib.sourceforge.net/. You will just need to copy all the contents of bin folder from NAntContrib to NAnt bin folder, and you are done. You will start getting all the advantages of NAntContrib as well.

NAnt’s configuration file is named like FileName.build. It’s an xml file as well, so no need to worry about any specific structure. Just need to get familiar with its tags. Sample script is as follows:

<?xml version=”1.0″?>
<project name=”ProjectName” default=”build” basedir=”.” xmlns=”http://nant.sf.net/schemas/nant-0.85.win32.net-1.0.xsd”>
<description>Write down any description</description>

<!– ********** –>
<!– Properties –>

<!– Solution.Filename represents the filename of the solution to build –>
<property name=”Solution.Filename” value=”DrivePath:\Project.sln”/>
<property name=”Solution.Configuration” value=”RELEASE”/>
<property name=”Build.OutputFolder” value=”Drive_Path\BuildLocation\”/>
<!– End Properties –>

<!– build will trigger main build –>
<target name=”build” description=”compiles the source code”>
<call target=”runGetLatest”/>
<solution solutionfile=”${Solution.Filename}” outputdir=”${Build.OutputFolder}${sys.version}\” configuration=”${Solution.Configuration}”/>
<call target=”runUnitTests”/>
<call target=”runFxCop”/>
<call target=”runCreateDocumentation”/>
<call target=”runCopyResults”/>
</target>
<!– End Targets –>

<target name=”runGetLatest”>
<vssget
user=”username”
password=”pwd”
localpath=”PathToGetCode”
recursive=”true”
replace=”true”
writable=”true”
removedeleted=”false”
dbpath=”\\Path\VSS\srcsafe.ini”
path=”$/DirNameInVSS”
/>
</target>

<!– runUnitTests will run the nunit task on the test dlls –>
<target name=”runUnitTests” description=”Runs unit tests on specified dlls”>
<nunit2 failonerror=”false” verbose=”true”>
<formatter outputdir=”${Build.OutputFolder}${sys.version}\” usefile=”true” type=”Xml” extension=”.xml”/>
<test>
<assemblies basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”*Test.dll”/>
</assemblies>
</test>
</nunit2>
</target>

<!– runFxCop will run the fxcop file of the same name as the nant project –>
<target name=”runFxCop”>
<exec program=”DrivePath\fxcop\fxcopcmd.exe”
commandline=”/p:${nant.project.basedir}\${nant.project.name}.fxcop /o:${Build.OutputFolder}${sys.version}\fxcop-results.xml” failonerror=”false”/>
</target>

<!– runCreateDocumentation will create msdn type documentation for the building solution –>
<target name=”runCreateDocumentation” description=”Will create documentation for Buidling Solution”>
<ndoc>
<assemblies basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”ProjectAssembly.dll” />
</assemblies>
<summaries basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”Project.xml” />
</summaries>
<documenters>
<documenter name=”MSDN”>
<property name=”OutputDirectory” value=”${Build.OutputFolder}${sys.version}\doc” />
<property name=”HtmlHelpName” value=”ProjectNAme” />
<property name=”HtmlHelpCompilerFilename” value=”hhc.exe” />
<property name=”IncludeFavorites” value=”False” />
<property name=”Title” value=”ProjectName” />
<property name=”SplitTOCs” value=”False” />
<property name=”DefaulTOC” value=”" />
<property name=”ShowVisualBasic” value=”True” />
<property name=”ShowMissingSummaries” value=”True” />
<property name=”ShowMissingRemarks” value=”True” />
<property name=”ShowMissingParams” value=”True” />
<property name=”ShowMissingReturns” value=”True” />
<property name=”ShowMissingValues” value=”True” />
<property name=”DocumentInternals” value=”False” />
<property name=”DocumentProtected” value=”True” />
<property name=”DocumentPrivates” value=”False” />
<property name=”DocumentEmptyNamespaces” value=”False” />
<property name=”IncludeAssemblyVersion” value=”False” />
<property name=”CopyrightText” value=”" />
<property name=”CopyrightHref” value=”YourCompURL” />
</documenter>
</documenters>
</ndoc>
</target>

<target name=”runCopyResults”>
<copy todir=”${Build.OutputFolder}Latest\”>
<fileset basedir=”${Build.OutputFolder}${sys.version}\”>
<includes name=”*-results.xml” />
</fileset>
</copy>
</target>
</project>

In the above you will find tags for getting latest source, building the solution, running fxCop & NDoc. I have shown in this sample some tags that may help to get started with CC.Net and NAnt.

admin Misc automated build, build, build server, change control, code generator, continuous integration, cruise control, cruisecontrol, nant, software build automation

Problem

We have discussed automated deployment in another post, now let’s discuss how we can install a feature. Doing an automated feature installation contains some problems if we use SDK. For these problems, please keep on reading.

Solution

The following code snippet should install a feature on the form.

SPWebApplication app = SPWebApplication.Lookup(new Uri(DefaultZone));
SPFeatureDefinitionCollection col = farm.FeatureDefinitions;
SPFeatureDefinition def = col.Add(featurefile, id, true);
app.Features.Add(id, true);

The above code installs the feature but it do not activate the feature even if we try to activate it. The activation step needs to be performed manually.

If we wanted to somehow perform this step, we can do it using the following code (this does not use the SDK):

ProcessStartInfo pStartInfo = new ProcessStartInfo();
//specify gacutil.exe whith which to start the process
pStartInfo.FileName = @”.\stsadm.exe”;
pStartInfo.Arguments = string.Format(“-o installfeature -filename {0} -force”, featureName);
pStartInfo.UseShellExecute = false;
pStartInfo.CreateNoWindow = true;
pStartInfo.WindowStyle = ProcessWindowStyle.Hidden;

//start the process
Process process = Process.Start(pStartInfo);

//wait till the process completes
process.WaitForExit();

The above code will install the feature on the farm where this code is being executed. If we wanted to activate it as well, we can write down the same statements with activatefeature switch.

admin SharePoint feature activation, feature installation, MOSS, sharepoint backup, sharepoint deployment, sharepoint export, sharepoint portal, sharepoint workflow