New in version 1.4 is a method to assert that the execution time of particular method or action does not exceed a predefined value. To verify the execution time of a method, use the following syntax:

var subject = new SomePotentiallyVerySlowClass();
subject.ExecutionTimeOf(s => s.ExpensiveMethod()).ShouldNotExceed(500.Milliseconds());

Alternatively, to verify the execution time of an arbitrary action, use this syntax:

Action someAction = () => Thread.Sleep(510);
someAction.ExecutionTime().ShouldNotExceed(100.Milliseconds());

Since it doesn’t make sense to do something like that in Silverlight, it is only available in the .NET 3.5 and .NET 4.0 versions of Fluent Assertions.

Make sure to set a sensible execution limit – bear in mind who’s running the tests (might be slow hardware – false negatives ahoy). It’s considered polite to put a Category attribute with a “Slow” value so people can exclude long running integration tests.

param([string]$rootPath)

$sln_files = Get-ChildItem -Filter *.sln -Recurse -Path $rootPath

$fails = @{}
$passes = @{}

foreach($sln in $sln_files)
{
    try
    {
        $sln.FullName
        $clean = "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe """ + $sln.FullName + """ /t:Clean /m"

        Write-Host $clean

        Invoke-Expression $clean
        $build = "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe """ + $sln.FullName + """ /t:Build /m"

        Write-Host $build

        Invoke-Expression $build

        if($LastExitCode -ne 0)
        {
            Write-Host "########## FAIL ########"
            $fails.Add($sln.Fullname,$sln)
        }else
        {
            Write-Host "########## PASS ########"
            $passes.Add($sln.FullName,$sln)
        }

    }
    catch
    {
        $fails.Add($sln.FullName,$sln)
    }
}

Write-Host $fails.Count Failed
Write-Host $passes.Count Passed

Write-Host "FAILS"
$fails
Write-Host "PASSES"
$passes

I just set it off against a big pile o’ code (some gnarly, some clean) and the results are pretty much as I expected.

Groucho Marx

Some of the rules about computers and systems are so fundamental that a child of five (in this case, rather fortuitously, Loki) can understand it and extrapolate extra rules (or scenarios).

Starting from two statements:

• A computer can only do what it’s told to do, by humans
• Computers don’t make mistakes, humans do

He was very quickly able to reach these conclusions:

• A computer can’t do what it’s not been told to do
• If a computer makes a mistake, it’s because a human made a mistake

He doesn’t quite understand the nuance of how many humans could have made the mistake (he only considers the user at the moment, not the pile of software engineers / QA / project managers / etc hidden behind the curtains), but the seed is there.

Pedants may now bang on about hardware failure

There are plenty of times that something really is a NEVER do that (like say Locking another mans Type or Reading the Stream.Read fine print) but those aren’t preferences. They’re hard factual instances where something will break if you keep doing it that way.

Your reasons for a choice are your own, they’re never someone elses reason, and that someone else will have different reasons for doing it the way they are. Respecting different opinions is vital!

With suitable materials they set to work, Loki dictating the design whilst Lerryn guided him in terms of what would actually work. He’d apparently already worked out how to do the hands when we were in the store – making sure to get exactly ten of the pieces of tubing he’d picked for fingers.

Out of the box, TeamCity will give you runners for (in a .NET environment):

MSBuild, NAnt, NUnit (with code coverage from dotCover, free), StyleCop, FxCop, Duplication analysis and MSTest.

Builds can be triggered on a variety of criteria: commits, date/time, frequency and other builds completing,.

Note the MSBuild runner – primarily you’ll want it for compiling your code, but MSBuild is a useful extension point for more complex build types. Imagine a build that can push itself into a test environment ready for user feedback with no human hand touching it (and screwing it up).