XPCShell test output changes

Those of you using XPCShell tests may notice some slightly improved output from the test macros that landed recently on mozilla-central.

Previously, if you called do_check_null(null), you would get an output that was similar to:

[TEST-PASS] null == null

However, if you tried do_check_null("null"), you would get an output that was similar to:

[TEST-FAIL] null == null

This isn’t very helpful, and I ran into this exact issue while working on some code that uses observers. Since the data is passed as JSON, when JSON.stringify(null) is called the result is “null”. The test runner showing null == null as a failure isn’t too helpful 😛

With this recent change, all string arguments will be adorned with double-quotes.

This means that calling do_check_null("null") will now output:

[TEST-FAIL] "null" == null

The same change was made for all of the other do_check_* and do_print macros.

Google Test only executing one test?

Earlier today while pair-programming, Angie and I ran into an issue where Google Test was only executing one unit test of the 150 or so in our test suite. We weren’t sure what the cause could be. We switched machines and all the unit tests ran fine on my machine.

We first checked the WinMain entry point to see if some configuration flag of GTest had been accidentally flipped. A quick diff showed us that nothing had changed.

So what could be differentiating Angie’s computer from mine? Well it turns out that Angie really enjoys using keyboard shortcuts and macros to help her do her work. A couple weeks ago I showed her some of the Visual Studio macros that are used in developing for Chromium. Angie saw the list of macros and quickly installed the “Alternate between source and header file”, as well as the “Run the currently selected google test”.

It  turns out that the “Run the currently selected google test” works by adjusting the command line arguments that are passed to the GTest executable. This argument sets a filter on the test runner to only run the tests that match the given filter, which in this case happens to be the name of the currently selected test.

As the Jing states, simply clearing out the command argument fixed our problem. If you’re using the macro mentioned earlier, you can also place your cursor outside of a specific test case, run the macro, and the filter will be cleared.

I hope this post comes in handy for anyone else that got stuck in our position.

Using Sikuli IDE to test a Google Chrome Extension

On Christmas Eve I decided to start working on my first publicly available Google Chrome extension. I blogged previously about it, but today I wanted to cover how I test that the extension is working.

The extension allows a user to take a YouTube video and bring it to the full window size of the browser. This creates a full screen that will not exit when another window is clicked on.

To use the extension, there is a “page action” that is located in Google Chrome’s address bar. When clicked, the video will either expand or contract. After the initial release, I made public the manual test cases for the extension. When I found time later, I automated them with Sikuli.

Here is a video of the test cases being run:

I have uploaded the Sikuli test case files to the project website as an example on unit testing with Sikuli.

Previously, I’ve used Selenium IDE for web-based testing and I know of some coworkers that use AutoHotkey. Have you ever used an app like these for unit testing?

Unit testing code behinds in ASP.Net Web Forms

Have you ever inherited an ASP.Net website with waaaaaaay too much logic in the code behinds?

A while back I came up with a solution to solving this problem. I don’t have a name for it, but if you do, please leave a comment at the end of this post.

The problem that I was trying to solve is that I wanted to make a new page and implement it using Test Driven Development. The hard part was that there was a lot of code that basically dealt with the visual aspect and interaction of the page but not much with the data model. I needed to find a way to write tests around this code, as the data model code already had a framework for writing tests.

Here is an example of the before-case:

public class CodeBehind : System.Web.UI.Page {
   protected void btnFindUser_Click(Object obj,  EventArgs e) {
      if (Page.IsValid) {
         var dbConnection = new DatabaseConnection();
         var users = dbConnection.GetUsers( txtQuery.Text );
         if ( !users.empty() ) {
            dataTable.Bind(  users );
         }
      }
   }
}

What I came up with was an introduction of a “controller” class that lived outside of the ASP.Net Web Forms project. Here is an example of the after-case:

// CodeBehind.aspx.cs
public class CodeBehind : System.Web.UI.Page {
   protected void btnFindUser_Click(Object obj,  EventArgs e) {
      controller.FindUser( Page.IsValid, txtQuery.Text, dataTable );
   }
}

// CodeBehindController.cs
public class CodeBehindController {
   public void FindUser( bool pageIsValid, string query, DataTable dataTable ) {
      if ( pageIsValid ) {
         var dbConnection = new DatabaseConnection();
         var users = dbConnection.GetUsers( query );
         if ( !users.empty() ) {
            dataTable.Bind( users );
         }
      }
   }
}

// CodeBehindControllerTests.cs
public class CodeBehindControllerTests {
   public void FindUser_WithNoUsersFound_DataTableIsEmpty() {
      DataTable table = new DataTable();
      CodeBehindController controller = new CodeBehindController();

      controller.FindUser( true, "ImpossibleUserToFind", table );

      Assert.IsTrue( table.empty() );
   }
}

With that, I can now mock out the DatabaseConnection and the DataTable and I’m good to go. By passing in Page.IsValid instead of the whole Page object, I’m able to provide types that are easier to instantiate and I also now have code with less dependencies.

Getting this to work is actually very simple. Just introduce another class and put all of your logic in that class. There shouldn’t be a single conditional in your *.aspx.cs page. As long as you follow this pattern, it should be pretty easy to TDD your next ASP.Net Web Forms page.

Any questions? Leave a comment and I’d be glad to help.

Finished Reading Clean Code

Today I finished reading Clean Code by Robert Martin aka Uncle Bob. I found out about the book from some coworkers during our weekly programming-discussion meetings. The book claims to leave its readers understanding:

How to tell the difference between good and bad code

How to write good code and how to transform bad code into good code

How to create good names, good functions, good objects, and good classes

How to format code for maximum readability

How to implement complete error handling without obscuring code logic

How to unit test and practice test-driven development

Part 1: Principles, Practices, and Patterns

I really liked part one of the book. The principles, practices, and patterns are well thought out and provide a style of programming that is, unfortunately, rarely seen. Since reading this part, I’ve been writing smaller functions (about 4-5 lines at max) and have seen a payoff in the amount of reusability and readability. Chapters 1-7 read quickly, are informative, and are really great pieces to read.

Part 2: Case Studies

The pace of the book really drops off after chapter 7, and each subsequent chapter I lost more of that urge to pick up the book and continue reading. The final nail in the coffin that actually put me to sleep once was the Case Studies part (chapters 14-16). The example of the Args module was too large and my internal-brain compiler just couldn’t handle JITting three pages of code at once. I pushed through and read this whole part, but I wouldn’t recommend you doing the same.

Part 3: Code Smells

Part three is one chapter long and focuses on Code Smells. Code Smells are patterns in code that when seen give a bad taste in your mouth. They are implementations that shout that they could have been done better. The longer the code smells, the worse it gets, until finally the abomination that once started out as a faint odor now is the muskiness in the room that scares off developers from maintaining the module. This chapter is important to get familiar with. It might not be too useful to memorize the different smells, but knowing which ones exist is good enough, because you can always come back to this chapter to see how the code can be refactored.

Unit Testing

The last item I wanted to cover was unit testing. While the book mentions unit testing a lot, and devotes a chapter towards it, I don’t feel like developers will walk away from this book with an understanding of unit tests and test-driven development. Any developer looking for further understanding on unit tests should pick up a book that is devoted to the practice, since there is just far too much to cover in one chapter. I would recommend reading Test Driven Development: By Example.