• Post Calendar

    February 2020
    S M T W T F S
    « Apr    

Unicorn Series–Automated Testing

Headline: The only real way to be Agile is if you have healthy automated testing. (See Unicorn Series Overview for other topics.)


Let’s start with some results of the practices described here:

  • Quality: Customer reported bugs range from 1 to 10 per year, despite thousands of users
  • Cost: There is no dedicated testing team
  • Speed: Our objective (usually met) is to fix a bug within 1 day

Yes – better, faster, cheaper.


The most agile teams seem to have short sprints. Ours are 1 week. Yes – 1 week. On any given week we could release a new version of the software fully tested and ready to go.

I once worked on a team that required 2 months of testing after the last line of code was changed. (Ok… we all know that at least a few lines of code change each week…)

Why did it take so long to perform the tests? They were mostly manual tests.

Automated Testing Is Required

So the only way to make sure you can release is to complete your test plans which is only fast when they are automated.

Our Automated Tests

We have several layers of automated tests:

  • C# Unit Tests
  • Jasmine (via Chutzpah) TypeScript tests for AngularJS code.
  • Web User Interface Tests (via Selenium)

All of the C# and TypeScript tests run with every CI (Continues Integration) build. After each successful build, we run a CD (Continuous Deployment) release we run all the Web tests before swapping the slots in the Azure environment. After every commit a developer makes, all tests are run from these three layers so we catch failures almost immediately.

After every commit a developer makes, all tests are run…

These automated tests (C# and TypeScript) cover more than 90% of the code base.

Other Benefits

Other real benefits from this strategy include:

  • It is fairly easy to refactor code as requirements change with this level of test coverage. (See A Strategic Case for Unit Testing)
  • It is faster and easier for new developers to the team to contribute because 1) because the unit tests document the code, and 2) they can code with limited fear of breaking things.

I’ll work to be a bit more active on the Unicorn Series in the months ahead.

Abner Zachry 1932-2019

In Loving Memory of

Abner S. Zachry III 1932 – 2019

Abner Shelton Zachry, III passed away peacefully on Friday, January 11, 2019 in Denver, CO at the age of 86. He was born to Abner and Ethelbert (Herring) Zachry on May 5, 1932 in Fort Worth, Texas. He grew up in Texas and New Mexico, and graduated from Carlsbad H.S. in 1950. He served in the army and later received both his bachelor’s and master’s degrees from Texas A&M University. On August 4, 1956, Ab married the love of his life, Nellie Lee Jefferies, at St. Andrew’s Presbyterian Church in Houston, Texas. They were married for 57 years.
Ab loved trying new things – tennis, golf, photography, gardening, music, and computers to name just a few. His children were inspired by his lifelong love of learning. As a devoted public school teacher, he passed this love on to his students in Brenham, TX; Crane, TX; Kermit, TX; and Grand Junction, CO.
Ab was preceded in death by his beloved Nellie. He is survived by son, Karl Scott Zachry and wife, Lael Wiseman of Denver, CO; daughter, Karen Louise Gardner and husband, Wayne of San Antonio, TX; eight grandsons, five great-grandchildren, and his brother, “Pete” Zachry.
In lieu of flowers, the family prefers memorial contributions be made in his memory to the Denver Hospice at

Static Code Analysis with .NET Core 2.1

Headline: I prefer Microsoft.CodeAnalysis.FxCopAnalyzers over StyleCop.Analyzers.


Here are the two primary reasons:

  1. I can use rulesets I’ve used in the past
  2. I can share a ruleset across many projects for consistency
  3. Ok… 3. And there are tons of overly restrictive, or at the very least –very different, rules in StyleCop.Analyzeers.


I’ll just refer to these as StyleCop and FxCop for this post. FxCop was done in very much the same philosophy as the original FxCop.

Use Existing Rulesets

For almost 10 years now I’ve used either “Microsoft All Rules” (AllRules.ruleset) or “Microsoft Managed Recommended Rules” (ManagedRecommendedRules.ruleset). The first for code projects and the second for test projects (because we like to use unit test names with underscores for readability.).

I could not find a way to use existing rulesets with StyleCop.

I also have read Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Microsoft Windows Development Series) 2nd Edition at least twice. And if you read that you fully understand the reasoning behind all the rules.

Sharing Rules Across Projects

I have one solution with over 30 projects. StyleCop uses a tree structure under the dependencies to select which rules you want. I could not find a way to “Save” that information and then reuse it across different projects.

Where there is not graphical interface like .NET Standard projects for selecting rulesets for static code analysis, you can merely put something like this in your project file (notice line 6):

From .csproj
  1.   <PropertyGroup>
  2.     <TargetFramework>netcoreapp2.0</TargetFramework>
  3.     <Description>Low level library for basic coding.</Description>
  4.     <NeutralLanguage>en-US</NeutralLanguage>
  5.     <Copyright />
  6.     <CodeAnalysisRuleSet>..\..\AllRules.ruleset</CodeAnalysisRuleSet>
  7.   </PropertyGroup>

So it is quite easy to share a common ruleset across projects.

Different Standards?

I won’t belabor the 3rd point… It’s a matter of opinion and I’m sure that there are people putting lots of hours in trying to make the world of coding a better place. But with all the thought that went into Framework Design Guidelines, and then more than a decade of use for these rules, I’m not ready to unleash a new set on existing code bases.

My experience shows that if you change the rules on a code base with 200,000 lines of code you will generate thousands if not 10’s of thousands of code analysis warnings. And at that point, everyone just ignores them and starts to inject some serious ones by comparison.

Steps I Took

  1. I used NuGet to install Microsoft.CodeAnalysis.FxCopAnalyzers in all my projects.


   2. I then unloaded the projects and added the <CodeAnalysisRuleset> line shown above.

   3. Then I just ran Code Analysis on the solution and all my warnings (put there on purpose to test) showed up!


Thank you Microsoft for developing Microsoft.CodeAnalysis.FxCopAnalyzers for .NET Core. It’s not as easy to use as Static Code Analysis in the past, but better than any alternatives I could find.

Since 2008 I’ve participated in many code bases that have zero code analysis warnings (unless suppressed in Source with a valid Justification) when using the Microsoft All Rules. And our code is much better for it. Thanks!

Getting a UPS package at Lombard Gate

UPS is great about delivering, but you do need to pick up your packages in a timely manner.

I signed up for UPS My Choice. It’s free and it’s great. So now I get an email that looks like this:


And if I go to that tracking number, I can sign up to be notified!


Clicking on the “Notify me with Updates” I get this:


I choose “All Packages”… There are quite a few options… and you can choose E-mail or SMS Text. The most important for me is “Delivery Confirmation”… Because then I know to go down and pick up the package.


I hope this helps…



Unicorn Series Overview

Headline: All the modern software development practices really do make significant business impact.


Disclaimer: As usual, there is not information in this series that would be considered proprietary information for C&C Reservoirs.

This is the overview and index for a series on software development practices the team I’m leading has been using for the past several years. But let me set some context.

This is called the “Unicorn Series” because several people that saw our practices said, “You’re a unicorn!” This mythical creature

that is said to exist, but now one has ever really seen it. Sometimes when someone says that they mean, “I don’t believe you.” But since I was able to demonstrate these practices, it clearly meant, “Wow! People say this, but not one really does all this!” (Someone else’s words, not mine.)

The overall objective was to take a content delivery and analysis software system for C&C Reservoirs and make it easy so we could "cross the chasm" – make it easy to use and appeal to the majority of the market. The team was given the liberty to re-write the application from the ground up. Now DAKS™ IQ is fast, easy to use, and high quality.

The key results are:

  • Better to use: In only 15 months we transitioned 100% of our customers from the previous software to DAKS IQ.
  • Available: Using cloud technology the uptime for this year so far is 99.95%.
  • Quality: The current rate of customer reported bugs is about 1 bug per month.
  • Fast: The use of cloud computing to place the application near the user and other techniques leaving the impression for most that it is a desktop application rather than a web application.

I started with key customer benefits which we all know are critical for business success. But there are other business benefits that aren’t customer facing. These help with costs and lead to the benefits above:

  • Unit Test Code Coverage: The code has greater than 90% coverage by unit tests.
  • Cloud Strategy: We don’t even own a server! We use Visual Studio Team Services (VSTS) for our source control, builds, and releases. And we use Azure for our deployments.
  • Continuous Deployment Builds: Each build runs all the unit tests, some web tests, and then deploys the build to a test site after every single check-in.
  • Mobile First: We started with a responsive application that would work on all devices from the first deployment.
  • Previews: We had 6 preview releases soliciting customer feedback before our first official release.
  • One Week Sprints: The team moves fast and is really ready to release on any day, but most certainly each week by the sprint meeting.
  • Technology Stack: We used the latest technologies. There are too many to mention here, but I’ll cover that in detail.
  • Automated Releases: When a release is kicked off all the databases are updated, each server around the globe is updated, and this is done with swapping slots to eliminate/minimize downtime.
  • Feature Focus: Each feature is hidden behind that feature and any modules can be created from a collection of features. This means that we can release the software with brand new features that customers don’t yet see.
  • No Branching: Due to the ability to construct features on the main branch and not release them there are no branches! And it has been that way for more than 2.5 years.
  • No Dedicated Testing Team: We do test, but various users in the company put it through the paces. Due to the extensive automated testing we don’t need a dedicated team like many software development teams.
  • Focus on Usability: We continually look at the usability for each feature and the consistency of the conceptual model that allows the user to easily navigate DAKS IQ.
  • Virtual Team: We had team members in Houston, Denver, San Francisco, Seattle, and China. Use of Visual Studio Team Services (VSTS), Skype for Business, and Slack allowed us to work together very effectively.
  • Security: We focused on security from the beginning. We don’t even store passwords and all content is delivered over https.
  • One Team: There isn’t a maintenance or bug fix team. We all work on features and what few bugs there are. The person most capable of fixing the bug works on it, which means that for the most part, the person that wrote the bug fixes the bug.
  • Dogfooding: We use DAKS IQ internally to capture the data for each of our fields and reservoirs.

I’ll explore many of our team practices including those mentioned that allow us to achieve these results. Let me know what you find the most useful.



Getting Started with Git in VS 2017

This talks about some basic steps for getting started with Git repositories in Visual Studio 2017. This doesn’t talk about overall usage, but rather just how to get some things setup.

Visual Studio 2017 already comes with basic support for Git. In this post I’m using Visual Studio 2017.3.3.

The first think I did was create a Git repository (repo) in VSTS (Visual Studio Team Services). You can see the + New repository option in the image below. I created the one called Playground.


After that I connected to that Repo and Cloned it.


After connecting to a Git repo then I see this on the Team Explorer tab:


When I click on Install, I see this disclaimer:


Then clicking that install, I go to a page that seems to download the right version for my by just landing on the page. I pressed Run.


Then when the Install started I clicked Next 9 times (took the default each time).

I then went to this page to get Git LFS: https://git-lfs.github.com/ 

And I clicked the similar link:


After that I did a Sync with the VSTS repo and all was well. Ok… That’s a lie. This process caused some local changes so the pull didn’t work. I had to do to the command prompt and type “git checkout .” to undo all the changes (3 of them) to my local copy. Then the Sync worked.

Some key notes…

– I had already added the items I wanted to track from another machine and committed those changes to the remote (VSTS) repo.

– If this is your first machine for the project that is using git LFS then you will need to run the track command to add them. As you can see, if I run just “track”, it shows which items I’m tracking with LFS:


You can add other files by running the git lfs track command, for example:

git lfs track “*.png”

adds the right information to the .gitattributes file.

Windows Live Writer 2012 in June 2017

Some day OpenLiveWriter will replace Windows Live Writer (I hope)… But for now I use the Paste As Visual Studio Code plug in, and at the time of this writing, there’s nothing like that for OpenLiveWriter.

Fortunately, at the bottom of this page is a location where you can download wlsetup-all.exe: https://answers.microsoft.com/en-us/windowslive/forum/livemail-wlinstall/windows-essentials-2012-microsoft-offline/0dbbd92a-991c-48d7-8157-26decd351da8

Then, there are many posts that show this command to actually install it without having the application call out to the web for updates, which results in an error message. Here is that command (all one line):

wlsetup-all.exe /AppSelect:Writer /q /log:C:\temp\Writer.Log /noMU /noHomepage /noSearch

I finally have a location where I’m keeping this file… Those guys did this right the first time.

No Startup Sound for Windows 10

At least by default it doesn’t seem there is a startup sound. This is GREAT!

I travelled this week and have no idea how many times I heard the Windows 7 startup sound. Why do you need a sound? The only real reason I can think of is because the startup is so slow. The user has gone on to other tasks and you need to let them know, “Hey! I’ve actually done something now.”

But Windows 10 on my Surface Pro 4 is pretty fast for booting. It’s so nice to open it up in a meeting and not have to lunge for the volume so you don’t disturb the meeting.

Stated a different way, LOTS of people this week disturbed others as they started up their devices. They respond with a sheepish and embarrassed smile, but it’s not really their fault – it’s Microsoft. Or was. But not any more.

Thank you Microsoft for realizing that just starting a device isn’t noteworthy of announcing the the entire room or airplane.

Yours truly,

An Introvert

How can I unit test unsubscribing from an event? (C#)

I’ve seen some strange bugs that occur when you don’t properly unsubscribe from events. But it seems I’m always stuck when it comes to unit testing that.

Well, I use Moq for most of my mocking and there are some techniques you can use for testing that your subscribed, namely by Raise(ing) the event in a mock.

But I always struggle when trying to see if I actually unsubscribe in my code. Here is a simple sample that shows how you can do it with very little code.

Here is all the code:

Code Snippet
  1. public interface IHasEvents
  2. {
  3.     event EventHandler BeginRequest;
  4. }
  6. public class ClassUnderTest
  7. {
  8.     internal IHasEvents ClassWithEvents { get; set; }
  9.     public ClassUnderTest(IHasEvents classWithEvents)
  10.     {
  11.         ClassWithEvents = classWithEvents;
  12.         ClassWithEvents.BeginRequest += OnBeginRequest;
  13.     }
  14.     public void Dispose()
  15.     {
  16.         // Yes… there are code analysis warnings here… But I want to keep simple.
  17.         ClassWithEvents.BeginRequest -= OnBeginRequest;
  18.     }
  20.     public void OnBeginRequest(object sender, EventArgs e) { }
  21. }
  23. public class MockHasEvents : IHasEvents
  24. {
  25.     public int BeginRequestSubscriberCount { get; set; }
  26.     public event EventHandler BeginRequest
  27.     {
  28.         add { BeginRequestSubscriberCount++; }
  29.         remove { BeginRequestSubscriberCount–; }
  30.     }
  31. }

And here is the code that tests that the constructor subscribes and the Dispose() unsubscribes.

Code Snippet
  1. [TestClass]
  2. public class ExampleEventMockTest
  3. {
  4.     [TestMethod]
  5.     public void Constructor_Subscribes_To_BeginRequest()
  6.     {
  7.         // Arrange
  8.         var expected = 1;
  9.         var hasEvents = new MockHasEvents();
  11.         // Act
  12.         var subject = new ClassUnderTest(hasEvents);
  14.         // Assert
  15.         var actual = hasEvents.BeginRequestSubscriberCount;
  16.         Assert.AreEqual(expected, actual);
  17.         //actual.Should().Be(expected); // I usually use FluentAssertions.
  18.     }
  20.     [TestMethod]
  21.     public void Dispose_Unsubscribes_From_BeginRequest()
  22.     {
  23.         // Arrange
  24.         var expected = 0;
  25.         var hasEvents = new MockHasEvents();
  26.         var subject = new ClassUnderTest(hasEvents);
  28.         // Act
  29.         subject.Dispose();
  31.         // Assert
  32.         var actual = hasEvents.BeginRequestSubscriberCount;
  33.         Assert.AreEqual(expected, actual);
  34.     }
  35. }

I hope this helps others.

Live Writer Lives On!

This is my first blog post being written from Open Live Writer. I suspect there are so many people to thank that I wouldn’t even know where to start.


I’ve used Live Writer for years to create blog posts. When it looked like Live Writer would go away I probably tried 10 other authoring tools (too long ago to remember which ones). And each time I thought, “But Live Writer did it right. It’s easy. It meets my needs.” So I was thrilled when Microsoft agreed to allow it to become open source.

Below is an image of Windows Live Writer on one computer and Open Live Writer on the other. You can’t really tell the difference!


Of course I guess one place to start thanking is Microsoft and Microsoft employees for making the source code available and the decision to allow it to become open source.  Of course, I’m sure that’s when the real work began and I see the list of contributors on the site is quite long. Thank you all!