# Friday, October 22, 2010

At my current client I was tasked with implementing coding standards and styles and developing a process so the configurations can be easily maintained and shared.  ReSharper was already in place at the client and the since 99% of what they wanted to enforce, initially at least, was style related I chose to combine ReSharper with StyleCop.

After looking around the interwebs for awhile I realized this process is either impossible or undocumented…or both.

The process I came up with is about 90% of what I was hoping and still requires two manual steps by the developer but overall it is solid.  So, let’s get started.  First download and install the following tools:

  1. StyleCop 
  2. StyleCop+

Although StyleCop+ is technically not required it does a great job with allowing you to extend and customize a lot of the built in StyleCop rules.  So I certainly recommend it.

The trick with StyleCop is that it will continue to look up the code tree for settings files and keep adding them together and then adds the settings file from StyleCop install directory to top things off.  That is unless you tell it to do otherwise.  What where going to do is first place a Settings.StyleCop file where all devlopers can access it.  Next we are going to place another at the root of our code directory.  So if your code resides at C:\Dev\Code then place the Settings.StyleCop file there.  We can then open up the settings file we placed out on the network that everyone has access to and tell it not to merge with any other settings file.  This will be the official settings file.

image

Next we will open the settings file in the root of our source tree and tell it merge only with the settings in the shared location.

image

Now once you make changes at the shared level they will be merged with each developers settings file.

Next we can deal with ReSharper…Stay Tuned!

posted on Friday, October 22, 2010 4:19:52 PM (Central Daylight Time, UTC-05:00)  #    Comments [10]
# Thursday, September 23, 2010

On this, my final day at my current employer, I have mixed emotions.

  1. Excitement – I am very excited to become a part of the Skyline Technologies family.  I feel that they certainly have the most to offer at this point in my career.
  2. Disappointment – I am disappointed that my vision of the future and my current employer’s vision could not align.
  3. Confusion – This is the emotion I am having the most difficulty with.  It all comes from when I asked myself “What did I gain from working for my current employer for the last 5 years?”  The first things that come to mind are experience and knowledge.  But does this have anything to do with my current employer?  As a consultant, to be completely honest, all my current employer did was arrange for the client and myself to speak.

 

I am going to stop there.  I don’t want to dwell in the past.  All I can say is that in the last 5 years I have grown more than I had in the previous 5 years and what more can you ask for.

Here is to the next 5 years….

posted on Thursday, September 23, 2010 8:54:19 AM (Central Daylight Time, UTC-05:00)  #    Comments [0]
# Friday, September 17, 2010

Earlier this week I got into a bit of spat with a couple of Tweeps on Twitter.  It started with someone I follow and respect re-tweeting something someone tweeted about him which basically said the tools which he is associated with aid developers in creating bad design.  I responded to this tweet in support of this person whom I respect by saying…

Tools don’t do bad design.  Bad developers do bad design.

Immediately after tweeting this I got multiple reply’s stating that just because you do bad design or write bad code you are not necessarily a bad developer. 

To be blunt…this confused the hell out of me.  If you knowingly create a bad design or write bad code how can you be a good developer?  I guess the key word in that previous statement is *knowingly*.  But if you don’t know what good design/code is in my book you can’t be a good developer.

Don’t get me wrong.  We have all been in the position when due to forces outside of our control we have been forced to write imperfect code or create a less than perfect design.  To me this is one place where you can quantifiably determine the good developer from the bad developer.  A good developer, when writing imperfect code due to factors outside of there control, will do one or more of the following:

  1. Get upset because they know they are writing less than perfect code/design.
  2. Leave a comment stating why the code/design was done in this factor.
  3. Add a ToDo for refactoring later.
  4. Will do the imperfect code/design in such a way that the refactoring effort will require less effort.

This argument of writing bad code does not a bad developer make really rattles me.  That is exactly what it does!

OK…Let me have it!

posted on Friday, September 17, 2010 8:58:51 AM (Central Daylight Time, UTC-05:00)  #    Comments [1]
# Friday, September 10, 2010

In the past 10 years I have gone from being an intern doing VBA in Access to architecting and coding enterprise level systems with some of the coolest technologies and methodologies.  I have learned so much, and have had a great time doing it.  Sounds perfect right…but not for me…I want more.  Up to this point, for the most part, I have done all this in a bubble.  Until recently I haven’t been overly involved in the development community and today I am officially declaring the end of that.

I have recently accepted a position with Skyline Technologies.  I am very excited about the opportunity of bringing my knowledge and experience to the group at Skyline.  I am going to use this new start as a spring board to getting more involved in the development community locally and beyond.

What really inspired me though was listing to John Sheehan on Rob Conery’s new podcast This Developer’s Life.  If you haven’t started listening to This Developer’s Life yet…do it…now!  In episode 1.0.2: Fame and Notoriety Rob talks to John Sheehan and Scott Hanselman about fame and how it relates to their careers.  Of course Scott was great, and hilarious, as usual but what I really enjoyed was John’s story.

In one particular part of the interview John details a point in his life when he decided to “raise his profile” and details what his goals where and how he was going to do it.  To me this sounded like a great starting point and what better to add that extra motivation than making it public! :)

Raising My Profile – a 12 month plan

  1. One substantial blog post per week.
  2. Speak at at least 6 user group meetings or conferences.
  3. Contribute to one or more open source projects.
  4. Raise my Twitter follower count to at least 250 legitimate followers.
  5. Become an MVP

So that’s my plan…and we will see how it goes!

posted on Friday, September 10, 2010 5:30:00 PM (Central Daylight Time, UTC-05:00)  #    Comments [0]

* Download Complete Source Code

In my previous post I covered doing automated user interface testing of a WPF application using Iron Ruby and Cucumber.  The reason I was drawn to this path was my current interest in Ruby, Rails, and BDD.  What made Bewildr such a draw for me, other than writing my tests in IronRuby, was the fact that I can use with Cucumber and have a truly human-readable natural language test.

  1. Scenario: The Log On window should be displayed on application start
  2.     Given I ensure that there are no instances of "CompositeAppPoc.Shell.exe" running
  3.     When I start "C:\\MyCompositeAppPoc.Shell.exe"
  4.     Then 1 window is displayed with name "Log On"
  5.       And Terminate the app

Again, because of the learning curve and the fact that I would be introducing a completely new programming language, and let’s face it a completely new way of thinking, into a corporate environment that I will not be around to support long-term I had to pursue a more conventional solution, which led me to White.

White is an automated UI testing framework similar to Bewildr in that they both rely on the MS UI Automation Framework to hook and manipulate the user interface.  What makes White a better choice given my current situation is that from a programmers perspective it is implemented and reads exactly like the standard .NET test frameworks.

  1. [TestMethod]
  2. public void OnApplicationStart_TheLogOnWindow_ShouldBeDisplayed() {
  3.     //Act
  4.     Window window = _app.GetWindow("Log On");
  5.     //Assert
  6.     window.ShouldNotBeNull();
  7. }

Take a look at the video clip below to see what running a White test looks like.

Getting up and running with White is very easy.  Other than downloading the binaries from CodePlex all you need is a tool like UISpy to help you dig deep into how the UI elements are rendered.

At the highest level White operates on the concepts of Application and Windows.  Application being the application you are testing and Windows being the main surface of the application.  As a best practice I would recommend spinning up the application, retrieving your window(s) and killing your application as part of test setup and teardown.

  1. #region Private Fields
  2.  
  3. private Application _app;
  4. private Window _window;
  5.  
  6. #endregion
  7.  
  8. #region Setup & Tear Down
  9.  
  10. [TestInitialize]
  11. public void MyTestInitialize() {
  12.     _app = Application.Launch(@"c:\pathtomyapp\myapp.exe");
  13.     _window = _app.GetWindow("MyWindow");
  14. }
  15.  
  16. [TestCleanup]
  17. public void MyTestCleanup() {
  18.     _app.Kill();
  19. }
  20.  
  21. #endregion

With all that in place let’s walk through setting up a couple tests.

The first thing I want to test is that when my application spins up for the first time the Log On window is displayed.  Because this is an Application level test I am going to put it in a test class called ApplicationTests.  I will use the practice of spinning up the app and killing it as I described above.  My test will simply attempt to retrieve a window with title “Log On” and make sure it is not null.

  1. [TestClass]
  2. public class ApplicationTests {
  3.     #region Private Fields
  4.  
  5.     private Application _app;
  6.  
  7.     #endregion
  8.  
  9.     #region Setup & Tear Down
  10.  
  11.     [TestInitialize]
  12.     public void MyTestInitialize() {
  13.         _app = Application.Launch(
  14.         @"c:\wpf\compositeapppoc\compositeapppoc.shell\compositeapppoc.shell\bin\debug\compositeapppoc.shell.exe");
  15.     }
  16.  
  17.     [TestCleanup]
  18.     public void MyTestCleanup() {
  19.         _app.Kill();
  20.     }
  21.  
  22.     #endregion
  23.  
  24.     [TestMethod]
  25.     public void OnApplicationStart_TheLogOnWindow_ShouldBeDisplayed() {
  26.         //Act
  27.         Window window = _app.GetWindow("Log On");
  28.         //Assert
  29.         window.ShouldNotBeNull();
  30.     }
  31. }

My next test is going to be to make sure that when I enter an invalid username and password and click the log on button a message is displayed telling me my credentials are not valid.  Because this test is specific to the Log On window I am going to create a new test class called LogOnTests.  I will use the practice of spinning up the app, getting my window and killing the app as I described above.  My test will enter an invalid username and password, click the log on button, and verify that the error message label is visible.

  1. [TestClass]
  2. public class LogOnTests {
  3.  
  4.     #region Private Fields
  5.  
  6.     private Application _app;
  7.     private Window _window;
  8.  
  9.     #endregion
  10.  
  11.     #region Setup & Tear Down
  12.  
  13.     [TestInitialize]
  14.     public void MyTestInitialize() {
  15.         _app = Application.Launch(
  16.             @"c:\wpf\compositeapppoc\compositeapppoc.shell\compositeapppoc.shell\bin\debug\compositeapppoc.shell.exe");
  17.         _window = _app.GetWindow("Log On");
  18.     }
  19.  
  20.     [TestCleanup]
  21.     public void MyTestCleanup() {
  22.         _app.Kill();
  23.     }
  24.  
  25.     #endregion
  26.  
  27.    [TestMethod]
  28.     public void Entering_InvalidCredentials_AndClickingThe_LogOnButton_ShouldDisplayThe_InvalidCredentialsMessage() {
  29.         //Arrange
  30.         _window.Get<TextBox>("txtUsername").Text = "InvalidUsername";
  31.         _window.Get<TextBox>("txtPassword").Text = "InvalidPassword";
  32.         var btn = _window.Get<Button>("btnLogOn");
  33.         //Act
  34.         btn.Click();
  35.         _window = _app.GetWindow("Log On");
  36.         //Assert
  37.         (_window.Get<Label>("lblErrorMessage")).Visible.ShouldBeTrue();
  38.     }
  39. }

It’s that easy.  With very little effort you can have a full suite of automated tests for testing your UI.  How cool is that!?

* Download Complete Source Code

posted on Friday, September 10, 2010 4:25:00 PM (Central Daylight Time, UTC-05:00)  #    Comments [6]