Claudio is a Principal Consultant at Improving Houston. He has been developing software for 25+ years. When not building software, consulting with clients, doing presentations, delivering training, or hanging out with his family, he can probably be found working on his music.


No GWT? No code!

As I mentioned in my post on Test Style: AAA or GWT, I’ve deliberately started thinking of everything in terms of GWT (Given-When-Then). So, when I’m beginning to write a new test, instead of writing this:

// Arrange
// Act
// Assert

I write this:

// Given
// When
// Then

Regardless of the style, though, if I can’t think of what should go in each one of those sections, I may have one of two problems:

  • I don’t have enough requirements, or
  • I don’t understand the requirements I have

I’ve gotten into the habit of thinking this way: No GWT, no code!

The reason for that is: if I either don’t have enough requirements or don’t understand the ones I have to a point where I can’t fill out my GWT sections, then I should NOT be writing any code. Whatever code I write is very likely to be thrown away, and unless I have a lot time in my hands to be simply toying with writing code, I should refuse to write any code and go find help to have a clear idea about what I’m supposed to implement.

Leave a comment

Test style: AAA or GWT?

Many years ago, after really getting into writing tests, I fell into the same trap newcomers do: my test code was very messy! Eventually, I heard of the AAA-style of organizing test code. AAA stands for Arrange-Act-Assert. There are several posts out there that show it. Here’s a link to one, in case you don’t know what this is all about.

After years of following that format, I learned about BDD (Behavior-Driven Development), and that’s where I learned about GWT (Given-When-Then).

Several years ago, I stopped thinking about AAA when writing any kind of test and got convinced that I should always think in terms of GWT. Why? Because AAA is too technical, while GWT works well both for technical people as well as for business or QA folks. Now, why’s that important?

For me, when I want to get feedback by having my code reviewed, if I stick with the GWT mindset, I can get pretty much anybody involved with the project to help me review my code. That means I can easily work with another developer, business analyst, or QA guy.

So, when I’m about to write tests, instead of thinking how I’m going to…

  • Arrange my test, I think what I’m Given
  • Act in my test, I think When something happens…
  • Assert the results, I think if that something happens Then this is what I expect as the outcome.

In both styles, the structure of the test is pretty much the same. However, this shift in how I approach coding makes me think more from a business-oriented point of view, and this mindset opens up possibilities regarding the number of people I can collaborate with in order to build a better product.

Leave a comment

Toggling Visual Studio CodeLens On/Off

As I’ve mentioned before (here, here, and here, at least), I’m very specific as to how much stuff I want to see on my screen as I’m working with code. Visual Studio can be very cluttered depending on how we set it up; so much so that sometimes I feel like just open my cs files in Notepad!

One of the things I think get in my way is the feature CodeLens in VS. While it does provide good information and access to useful things, I hate it being on my face all the time! I rather it only show me the goodies when I need it.

Gladly, I found information on this link that shows how I can create a shortcut to toggle CodeLens on and off (I’ve also found out about the Visual Commander extension, which I hadn’t seen before).

One thing in that post that wasn’t clear is the name of the command I need to bind the shortcut to. I thought it’d be the name of the command I created in Visual Commander, but that wasn’t the case. Editing the command in Visual Commander, I noticed Command01 right before the name I gave to the command:

And that’s what I needed to look for in the Keyboard dialog in VS:

I’ve bound the command to the Shift+Alt+CL shortcut (for CodeLens).

Now, if I toggle the feature On, I see all of the extra stuff it shows me:

Otherwise, I get to focus only on the code (which is what I want 98% of the time!):

The less stuff there is mingled in the code, the easier it is for me to read and understand it.

Leave a comment

SpecFlow: My preference for the step definition style

When using SpecFlow’s dialog to generate step definition skeletons, the default style is “Regular expressions in attributes”:

That produces results like this:

That looks very messy to me. The regular expression text can be read easily, but then the PascalCase method underneath looks like it is too much. I see redudant code. I see dead code. 🙂

I personally like the “Method name – underscores” style better:

That looks a lot cleaner to me. Yes, I am a little biased after having spent several years in Ruby-land, but hey, I had adopted this style in C# before that. While this is not a common format for method names in C#, I don’t really care, as nobody should be calling this methods in the common way anyway, so I rather follow a style that makes the code read better, without junk around that doesn’t add anything to my understanding of the code.

Note: by the way, I do rename those p0 and P0 references!!


Leave a comment

The “private” keyword in C#: I get rid of it!

I have a special dislike for walls of characters in code and I try to get rid of it whenever possible, as I mentioned in this other post. The keyword private in C# is another one that bugs me. Take the following code:

What do I see there?

I like this way better:

Every class member is private by default in C#, as it should be. We should always keep public members to a minimum, so I rather be explicit as to what’s NOT private in my classes. By removing the unnecessary private modifier keyword, I clean up my code. The less garbage there is around the code, the easiest it is for anybody to read and understand it.

For ReSharper users out there: you can set the tool so that it’ll remove “private” modifiers when you run Code Cleanup.


Leave a comment

A Good Example of Open-Closed Principle

Back in 2010 I wrote what became my most popular post in this blog: A Good Example of Liskov Substitution Principle, based on a scenario that came up in a project I worked on at the time. I just realized I’ve never blogged about another scenario that came up in the same project as a good example I use for the Open-Closed Principle (OCP), which is described as follows:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”; that is, such an entity can allow its behaviour to be extended without modifying its source code. – Wikipedia

I use a simple application to illustrate the scenario. This is a desktop application. The main menu has one sub-menu for each module (e.g., Orders and Employees). Each module has its own sub-menu to expose related functionality:

Initially, the menu was all implemented in the same place… the main window:

The “code behind” the main window called out services in the different modules:

Any time a new feature was added to a module, the main window had to be changed. With several features across several modules being written actively, the main window was a big bottleneck: many developers were trying to change it at the same time! Implemented that way, the main window violated OCP: to extend the menu (adding modules or features to them), the main window had to be changed.

In order to make the main window OCP-compliant, and therefore, improving the implementation, here are the changes made to app…

The main menu in the main window was defined, since it’s that window’s responsibility to host a menu. However, it is NOT its responsibility to know what items go in the menu. In other words, the menu is empty:

The code behind the main window that used to call services in the modules was removed, and the classes started to use an AppMenuBuilder class, which returned a list of MenuItems to be added to the menu. Each module was represented by a Module class (e.g.: OrderModule, EmployeeModule…). In the real world application these modules were registered and initialized automatically using an IoC container (but that’s beyond the point of this post).:

The AppMenuBuilder class simply registered IModuleMenuBuilder instances, and it used those to figure out what menu items were needed:

Each implementation of IModuleMenuBuilder was responsible for creating the menu items that the module needed, and what to execute when the menu item was invoked. See the OrderMenuBuilder as an example:

The MenuItemFactory offered an easy way to create the MenuItem and hook it up to the action to be executed:

Again, the real world implementation of that factory was slightly different: it implemented an IMenuItemFactory interface, which got injected into each Module class. But again, that part is beyond the point of this post. The idea behind having the MenuItemFactory was so to make it easy to hook other operations to the menu system-wide. For example, let’s say we wanted to log every action invoked by any option on the menu. Here’s a simple logger:

Here’s how the MenuItemFactory would leverage additional actions:

And once again, in the real world application this was a little more robust, where “things to be added to the menu actions” were registered automatically to the IoC container.

After making those changes, the main window became open for extension, but closed for modification: options could be added to the menu and actions could be associated with them, and the main window didn’t have to be changed.


Leave a comment

Baseclass Asking Subclasses for Items

There are many scenarios where a baseclass (often abstract) needs to defer to its subclasses the creation (or retrieval) of items it needs. For example, let’s pretend we have a Pizza class, which defers to its subclasses what ingredients it should have. I’ve seen developers implementing such scenario in ways that look like this:

public abstract class Pizza
    List<string> Ingredients { get; set; }

    protected abstract void AddIngredients(List<string> ingredients);

    public void Make()

public class MeatLovers : Pizza
    protected override void AddIngredients(List<string> ingredients)
        ingredients.Add("Canadian Bacon");

That kind of implementation has the baseclass call a method overridden in the subclass so it can populate the given list. I don’t like it implemented this way because it gives developers the idea that the list can be manipulated. For example, the developer might decide that before adding items to the list, he or she could/should empty the list first (ingredients.Clear()). Well, what if I want all of my pizzas to have cheese (I’m a cheesy guy!)?

I rather ask the subclass for the items, and then have the baseclass deal with adding them to a list, collection, array, or however it sees fit. Something like this:

public abstract class Pizza
    List Ingredients { get; set; }

    protected abstract IEnumerable<string> GetIngredients();

    public void Make()
        Ingredients = GetIngredients().ToList();

public class MeatLovers : Pizza
    protected override IEnumerable<string> GetIngredients()
        yield return "Pepperoni";
        yield return "Sausage";
        yield return "Canadian Bacon";

In simple scenarios, the subclass can simply use yield return for each item. For other cases, it can internally use lists, collections, arrays, or anything else that can ultimately produce an IEnumerable<string>.

With that being said, if the requirements calls for allowing the baseclass to manipulate that list, then I’d go with something similar to the first implementation. However, in most cases, that’s NOT what the requirements ask for, and I’ve had to troubleshoot several bugs where subclasses manipulated lists when they were not really meant to.

Leave a comment