The janitor's closet

Boise Code Camp Presentation on Into to Continues Integration

noreply@blogger.com (Bob The Janitor) — Mon, 26 Mar 2018 15:10:00 +0000

This year at Boise Code Camp I presented on Into to Continues Integration and here are the Slides and the source Code https://github.com/bobtjanitor/SampleTDDApp

Slides from my Into to TDD talk at Boise Code camp

noreply@blogger.com (Bob The Janitor) — Mon, 26 Mar 2018 15:00:00 +0000

This year at Boise Code Camp I presented on Into to TDD and here are the slides and the source Code https://github.com/bobtjanitor/SampleTDDApp

Unit Testing Asp.net MVC View Model Validation

noreply@blogger.com (Bob The Janitor) — Tue, 23 Feb 2016 20:40:00 +0000

ViewModel attribute validation is a key feature of ASP.NET MVC, but is often not a tested one. For the most part developers verify controller actions, pass in a model, mock the ModelState.IsValid property and call it good, never checking to make sure if the model is validating correctly. One of the biggest reasons is developers just don’t know how, it’s not difficult, but it’s not very intuitive so here is a quick tutorial.

First we take a view model with some basic validation attributes

   1:  public class RegisterViewModel

   2:  {

   3:      [Required]

   4:      [EmailAddress]

   5:      [Display(Name = "Email")]

   6:      public string Email { get; set; }

7:

   8:      [Required]

   9:      [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]

  10:      [DataType(DataType.Password)]

  11:      [Display(Name = "Password")]

  12:      public string Password { get; set; }

13:

  14:      [DataType(DataType.Password)]

  15:      [Display(Name = "Confirm password")]

  16:      [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]

  17:      public string ConfirmPassword { get; set; }

  18:  }

Next we create a simple reusable testing context class

   1:  public abstract class ViewModelValidation_Context<T> where T : new()

   2:  {

   3:      public T Target;

   4:      public List<ValidationResult> ActualMessages;

   5:      public bool Actual;

6:

   7:      [SetUp]

   8:      public void SetUp()

   9:      {

  10:          Context();

  11:          Because();

  12:      }

13:

  14:      public virtual void Context()

  15:      {

  16:          Target = new T();

  17:          ActualMessages = new List<ValidationResult>();

  18:      }

19:

  20:      public virtual void Because()

  21:      {

  22:          var context = new ValidationContext(Target, null, null);

  23:          Actual = Validator.TryValidateObject(Target, context, ActualMessages, true);

  24:      }

  25:  }

Notice this test context class is a little different than what I have used in the past, we are predefining the Because() method. In this case regardless of the class we are testing we are still going to run what is really the meat of this class, we create a Validation Context and then passes it to System.ComponentModel.DataAnnotations.Validator.TryValidateObject and this returns if the view model passed validation and and validation messages.

Next lets put this into action with a test to validate our model

   1:  [TestFixture]

   2:  public class When_Testing_RegisterViewModel_Validation_Test : ViewModelValidation_Context<RegisterViewModel>

   3:  {

   4:      public override void Context()

   5:      {

   6:          base.Context();

   7:          Target.Email = "TestEmail@email.com";

   8:          Target.Password = "TestPass";

   9:          Target.ConfirmPassword = "TestPass";

  10:      }

11:

  12:      [Test]

  13:      public void Passed_Validation_Test()

  14:      {

  15:          Assert.IsTrue(Actual);

  16:      }

17:

  18:      [Test]

  19:      public void Has_No_ValidationMessages_Test()

  20:      {

  21:          Assert.IsFalse(ActualMessages.Any());

  22:      }

  23:  }

The model validation requires we have a valid email, we have a password, a confirm password, and password and confirm password match, in this case everything is good and we get a true for is valid and no validation massages.

Next lets test an invalid model

   1:  [TestFixture]

   2:  public class When_Testing_RegisterViewModel_Validation_With_NoPassword_Test : ViewModelValidation_Context<RegisterViewModel>

   3:  {

   4:      public override void Context()

   5:      {

   6:          base.Context();

   7:          Target.Email = "TestEmail@email.com";

   8:          Target.Password = string.Empty;

   9:          Target.ConfirmPassword = "TestPass";

  10:      }

11:

  12:      [Test]

  13:      public void Fail_Validation_Test()

  14:      {

  15:          Assert.IsFalse(Actual);

  16:      }

17:

  18:      [Test]

  19:      public void Has_No_ValidationMessages_Test()

  20:      {

  21:          Assert.IsTrue(ActualMessages.Any());

  22:      }

23:

  24:      [TestCase("The Password field is required.")]

  25:      [TestCase("The password and confirmation password do not match.")]

  26:      public void Has_Expected_Validation_ErrorMessages_Test(string message)

  27:      {

  28:          Assert.IsTrue(ActualMessages.Any(x=>x.ErrorMessage== message));

  29:      }

30:

  31:      [TestCase("Password")]

  32:      public void Has_Expected__ValidationMessages_Test(string memberName)

  33:      {

  34:          Assert.IsTrue(ActualMessages.Any(x => x.MemberNames.Contains(memberName)));

  35:      }

  36:  }

In this test we made password an empty string and as a result it failed validation, and returned a validation message for password being required and for password and confirm password not matching.

Check out my sample application on Github to see this in action.

I agree With Apple and San Bernardino County is at fault

noreply@blogger.com (Bob The Janitor) — Thu, 18 Feb 2016 18:55:00 +0000

There is currently a court case in San Bernardino where the FBI is attempting to compel Apple to build an update to IOS that would allow them to access encrypted data on the work phone of Syed Rizwan Farook (Farook and his wife Tashfeen Malik were responsible, authorities say, for killing 14 people and injuring another 22 who were attending a training event and holiday party last December 2 ).

The FBI has requested and has been granted by Magistrate Sheri Pym, in the US District Court of Central California, a court order to force Apple to provide the FBI with software to defeat a self-destruct mechanism on the iPhone. Under the pretense that the phone belongs to the county and the county has the right to access any and all information on their device. To this Tim Cook (CEO of Apple) responded with an open letter to their customers saying they will not comply with the court order. Apple is not disobeying the court order because it supports murdering terrorists, but because they value the rights of their users and are not going to deliberately circumvent their security.

In a statements to Fox News one of the against working the San Bernardino case as stated “Nobody can build a phone that we cannot get in under unique circumstances. Why should Apple be allowed to build a phone that does that?” and “The right should not supersede our ability to keep people safe. It’s why we are not finding others, encryption, and, specifically in this case, we cannot connect the dots.” source. Here is where the DOJ, the FBI and the Judge is wrong and Apple is right. “Our Rights” to not self-incriminate do supersede, and are guaranteed by the constitution. To make this a little more clear the court order is basically the same as getting a court order to force MasterLock to update all of their padlocks to use a master key so the government can open them if they need to.

Regardless of who owns what is being locked, by forcing a company to add security vulnerabilities to their products is wrong, reckless, and fundamentally against everything our country was founded on. I understand the DOJ’s position but they are wrong.

Why San Bernardino is at fault, if you are going to issue devices as a company/government entity (this was a work phone) you should be managing your hardware to protect your assets, this is the basic bus factor. If an employee has a company device, the company owns it, and everything on it. Outside of this case what happens if an employee has valuable company information on a device and the person is in a car wreak? Digital assets, like all assets, need to be managed correctly, the device manufacture should not be forced to weaken their product for your bad planning.

Enterprise Design Patterns and Practices (Boise Code Camp 2015)

noreply@blogger.com (Bob The Janitor) — Mon, 23 Mar 2015 15:33:00 +0000

At this years Boise Code Camp I presented on Enterprise Design Patterns and Practices, afterwords I was ask to post my slide deck and notes, if there is interest I'm thinking of doing a blog series on this.

Fundamental principals

S.O.L.I.D. Principals

S - Single responsibility principle

· A class/method/tier should have only a single responsibility it should do one thing, and do it well, even if that is telling other things what to do.

O - Open/closed principle

· Software entities should be open for extension, but closed for modification, and always favor extension over inheritance.

L - Liskov substitution principle

· Design by contract, you should never need to care what the object really is.

I - Interface segregation principle

· Using multiple client-specific interfaces are better than one general-purpose interface.

D - Dependency inversion principle

· Depend use abstractions and not concreate implementations. Use a factory pattern, DI container, Lazy Load properties, etc.

These are the fundamental principles of OO development and apply equally for application architecture.

Be strongly typed and loosely coupled

By creating strongly typed interactions between objects you are enforcing a consistent behavior that will help prevent difficult to find runtime errors. Decoupling objects in your application allows you to change the underlying object without the changing the caller.

The 2 biggest problems you will face

Golden Hammer

Having go to tools are great, but just because something can do it, doesn't mean it should be used.

Silver Bullets

Everything from here on down may/can/possibly help, but will not solve all of your problems, always looking for the next technology to solve all of your problems will only end in pain. These are tools in a toolbox, to be used appropriately. If used incorrectly they will bring pain, lot of pain.

Automation, Automation, Automation

If it can be reasonably automated, it should be, Computers are really good at being consistent, and humans are not

Build server & source control

Nothing fundamentally improve your code more. (Jenkins, TFS, Team City, Bamboo, Apache Continuum, etc.) Nothing goes out that isn't in source control, EVER!

Application Deployment

Using deployment tools for pushing changes (MSDeploy, Octopus, etc.), copy past in not a recommended deployment methodology.

Database Deployment/Migration

Database changes are code changes too. Use a migration framework (EF Migrations, Fluent Migrations, etc.) or a database change management tool (Visual Studio Database Project, Redgate tools, DB Deploy, Ready Roll, etc.)

Testing

Automating your unit, behavior, integration, load and UX tests allows you to find problems before your clients/customers.

Instrumentation

Regardless of what you think might be going on, without instrumentation your blind.

Logging

This is the first and easiest way to find out what is going on under the hood, don’t write your own! Unless you really need to (log4net, nLog, Enterprise Library, SmartInspect, etc.)

Memory Profiler

While a logger can tell you what is going on in the code, a memory profiler (redgate ants, JetBrains Memory Profiler, etc.)

Site monitoring and Analytics

Just because your application is live doesn't mean you can stop paying attention to it, knowing how many people are interacting with it, how they are interacting with it and when will let you know what has happened, what is currently happening, in order to guess what is going to happen.

Leveraging 3^rd party tools

Focus on your core features, leverage 3^rd party to deal with the grunt work.

Abstract your 3^rd party includes

Using 3^rd party tools are great and will save you from re-inventing the wheel, but to keep from being locked in always abstract away the implantation when you can. In the future the library may no longer be supported, licensing problems, etc. being able to quickly insert a replacement will save you in the long run.

Building for Extendibility

Separate your application into logical segments or tiers.

n-Tier Design

The 3 major application tiers are (but not limited to)

· UI – For displaying or transmitting information (webpage, API endpoint, etc.)

· Domain or Business – This is where the work and decisions are made

· Data Access – Where the data comes from (DB call, Web Service call, file read, etc.)

A very important rule is tiers can only see the tier next to them, the UI should have no concept of where the data it’s displaying is coming from, and all it cares about is it made a request from the Domain and got data back. This applies to the Data Access as well, all it knows or cares about is returning data requested by the Domain. This logically separation of your logic allows you to reuse and refactor your application cleanly without fear of breaking changes in an outside tier.

DTO, POCO, and Model objects

With each tier isolated from each other we are going to need a way to pass information back and forth, enter the DTO (Data Transport Object). Basically these are classes that hold information, they have little to no logic and know nothing about where they are, where they came from, or where they are going.

Separate Update, Select and Work Logic

Domain classes can get big fast, by keeping them logically separated into a more singular function is keeping in line with the single responsibility principal and keep them more manageable.

This can be applied to Data access classes as well even if it’s as simple as having 2 interfaces on a data repository class, one for updates and one for selects. This might seem silly until you start working with publisher and subscriber databases.

Do not over abstract

While using abstractions to separate and decouple your logic is good, if overused/abused these good intentions quickly paves a road abstraction hell. Where adding a single property to your result set to display requires modifying 5 DTO objects, 4 file mappers, yes I know of an application that does this.

Building for Scalability

Dealing with Load

Caching

· Micro-caching – for lots of requests for the same data needing relatively real time data(5-10 sec)

· Memory caching – for things that don’t change that often (1+ hours): User information, product data, GEO data (city, state, LAT, LOG, etc.)

· DB caching – For sharing your Cache

Spreading the Load

With your logic separated and decoupled it’s easy to farm your pain points to other hardware, think out instead of bigger.

· Move expensive functionality (Encryption, PDF/Image creation, etc.) to a dedicated system/systems to prevent load on your main server/servers.

· Using publisher & subscriber data bases, to reduce the load on your primary database, move selects from the main to the subscribers, this is also a good practice for reporting servers, running a massive metrics report for the sales team should not affect production performance.

· Aggregate and pre-process data, just because you saved the data in a specific DB Schema don’t mean you have to keep it that way. Having a job that copies data to a more flattened table for faster searching can greatly improve performance, even more so when aggregating from a SQL server (MYSQL, MSSQL, Oracle) to NoSQL( CouchDB, MongoDB, etc)

Queuing up

If you don’t require an immediate synchronous response message queues are a great way to keep your system fast, prevent data loss (messages persist until client acknowledges receipt), and distribute workload. Using a Service Bus takes queues to the next level by creating an architecture for distributing work load.

CDN (Content Delivery Network)

Keeping your static files fast, having a striped down server that only serves up static like images, css, JavaScript, etc. these can also be geo-located for even better performance.

Not everything needs to go to the DB or come from it

Databases are great for storing data and pulling data but they aren't the only solution. Lots of data submitted by the use doesn't need to be persisted in the database. There are better ways to localize your site then storing it in the database. Customer uploading images are another area where keeping the Meta data in a database is a good idea but the image itself should probably go to disk to disk (a CDN would be great for this).

Redundancy

Hardware fails, systems crash, operating systems need updating, and redundant systems keep you online.

Here is the slide deck

Boise Code Camp 2014

noreply@blogger.com (Bob The Janitor) — Tue, 08 Apr 2014 21:35:00 +0000

This year I did a presentation at Boise Code Camp on "Creating Testable Mobile App with MVVMCross, Xamarin, Windows Phone, and Windows Store Apps. At the request of some of the attendees here is my slide deck also here is the source code.

Testing un-mockable base class methods

noreply@blogger.com (Bob The Janitor) — Thu, 28 Nov 2013 08:22:00 +0000

Working on a project using the Xamarin Framework and came across a problem where I needed to see if a method was being called. The problem was the method was on the base class and was un-mockable

To get around this I used a lazy load property and a delegate to create a wrapper.

private StartActivityDelegate _start;
   2: public StartActivityDelegate Start

{
    get { return _start ?? (_start = StartActivity); }
    set { _start = value; }
}
  
public delegate void StartActivityDelegate (Type type);
  
protected override void OnCreate(Bundle bundle)
{
    base.OnCreate(bundle);
    Redirect();
}
  
public void Redirect()
{
    if (Preferences.HasRequired())
    {
        Start(typeof(ClientActivity));
    }
    else
    {
        Start(typeof(SettingsActivity));
    }   
}

To test it you simply set the property in my test class to a test method

[TestFixture]
public class When_Starting_SplashScreen_Without_Required_Preferences_Test
{
    public SplashActivity Target;
    public Type Actual;
    public PreferencesMock PreferencesMock;
  
    public void TestStartActivity(Type type)
    {
        Actual = type;
    }
  
    [SetUp]
    public void SetUp()
    {
        PreferencesMock = new PreferencesMock { HasRequiredStub = false };
  
        Target = new SplashActivity { Start = TestStartActivity, Preferences = PreferencesMock };
        Target.Redirect();
    }
  
    [Test]
    public void Has_Expected_Activity_Test()
    {
        Assert.AreEqual(typeof(SettingsActivity), Actual);
    }
}

Next to test that we are calling the base class method we are expecting, we add a new test fixture and use a little reflection to get the method info for each and then compare them

[TestFixture]
public class SplashActivity_Tests
{
    public SplashActivity Target;
    
    [SetUp]
    public void SetUp()
    {
        Target = new SplashActivity();            
    }
  
    [Test]
    public void LazyLoads_Write_Test()
    {
        MethodInfo actual = Target.Start.GetMethodInfo();
        MethodInfo expected = typeof(Activity).GetMethod("StartActivity");
        Assert.AreSame(expected, actual);
    }      
}

Steps for shortening the “Feedback Loop”

noreply@blogger.com (Bob The Janitor) — Wed, 16 Oct 2013 20:09:00 +0000

Information is the basic building block of software development and the most valuable form of information is useful feedback. Feedback can come from the customer, the application’s users, and the development team.

Regardless of the development methodology used the feedback loop is going to follow this basic flow

Looking at the Waterfall Methodology it’s very easy to see why it has become dated. When you look at the basic flow

The first opportunity for the developers to get feedback is at the end of the Verification stage. Depending on the size of the project the Feedback Loop for Water Fall can take a couple of months to over a year. This large gap between gathering requirements and implementing them makes it very difficult and costly to fix misunderstood or faulty requirements.

What if the oil light in your car only gave you feed back every 30 min? If you lose your drain plug, 30 min. is a long time to run without oil. Software development is the same way, unless you’re getting regular feedback you won’t know something has gone wrong until it’s too late and you face costly refactors.

The hardest part of shortening the Feed Back loop is getting started. It takes not only a change in behavior but also in thinking. To quote a great American writer

“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and starting on the first one.”

― Mark Twain

Step 1: Short Development Iterations

A project may look large and complex but keep in mind the Egyptian Pyramids where built one block at a time. By breaking tasks down into more manageable items you are able to focus on very specific requirements and get feedback on that specific requirement. I personally like 2-week iterations; it’s enough time to get things done, without getting lost in the details.

Step 2: Work in Small Teams

The old adage “too many cooks spoil the broth” is just as true in software development. Large teams have the same problems that large tasks do; there is too much going on. Large teams require too much coordination, reduce individual responsibility, and only the most vocal get heard.

It has been my experience that three to five developers works best. With fewer developers the team can lack skill set diversity, and with more you run into coordination and crowd mentality issues. Never have a team of one.

Step 3: Test Driven Development

Test Driven Development (TDD) is creating software tests to verify requirements, and then writing the software to perform that behavior. This provides the developer with a personal feedback loop to know that what is being created has the expected result. This also provides the added benefit of built in regression tests.

Step 4: Continuous Integration

Continuous Integration (CI) is the process of merging code as soon as possible and running tests to verify everything is working as expected. CI can be done manually but is more commonly done with a build server such as Team City, Jenkins, TFS, or others. This quickly gives software developers feedback regarding overlapping work, quality control, and overall code health. This step will quantifiablly improve the quality of your code more than any other single task you do.

Step 5: Automate as much as possible

When automating tasks you are going to get quicker feedback, a consistent behavior, inherent documentation (by way of the automation script), and reduces overall costs by freeing up resources to work on more important tasks.

Death by Golden Hammer

noreply@blogger.com (Bob The Janitor) — Wed, 09 Oct 2013 19:57:00 +0000

The old adage “When all you have is a hammer, every problem looks like a nail.” is a very common problem in the software development world. Developers may become proficient with a particular technology or tool set and use it to every problem, even to the point of excluding a more appropriate solution. This narrow technological view has been nicknamed, “The Golden Hammer”. There are benefits to having a very deep understanding of a specific technology stack, however t is more important to understand when to use an alternative.

A common Golden Hammer is using programing languages in ways they were never intended to be used. For example, in the late 90’s the Perl programing language was very popular, and to some extent still is. With good reason, it’s an incredibly powerful and useful scripting language. It was originally created for parsing text, which it’s really good at it. It was so good at doing what it did, that people became very adept at it, and started using it for things it was never really intended to do; such as writing full applications. Being a scripting language created for simple text parsing, its syntax was very loose and lacked the structure needed to create well formatted and maintainable code. In spite of its shortcomings it was used far more than it should have been.

Another common Golden Hammer is using tools like Microsoft SharePoint or a content management system (CMS) such as:WordPress as a development platform. These tools were built with the intent of managing content, and for the most part they do that very well. The down side is when you start extending these tools beyond their intended use. Using Microsoft SharePoint to build a warehouse order management system is like building a drag racer out of a school bus. I’ve seen both done and it’s a prime example of “just because you can doesn’t mean you should.” You can force tools to do what you want them to do, but it’s going to take a lot of customization and your end product, like the drag racing school bus, will never perform as well as if you had built it with the appropriate solution.

When looking at what tools and technology to use it’s just as important to look at what not to use. One of the most valuable lessons I learned in high school was from my shop teacher:

“Learn to use the right tool for the job, not what’s most convenient. Screwdrivers are not chisels!”

Dallas E. Tolman

In the long run you will always be better off using the right tool vs. the most convenient one.

Having the right tools can make all the difference

noreply@blogger.com (Bob The Janitor) — Mon, 07 Oct 2013 19:54:00 +0000

The ability to make and use tools is what separates humans from the rest of the animal kingdom; having said that, there is a difference between having a tool and knowing how to use it.

When not developing software, I’m a woodworker. When I started building things, one of the first lessons I learned is that spending the money to get quality tools will save you money in the long run. Chisels made from high quality steel can be made sharper, and will hold an edge longer, allowing the user to make cleaner cuts and reduce waste in materials and effort. Quality development tools can do the same thing, with tools like intelli-sense, reference navigation, and auto test runners; we reduce the labor of development thus reducing the cost. The licensing for Visual Studio, Resharper, and NCrunch may look expensive until you look at the amount of time saved not having to wait for tests to run, not having to hunt through file after file when a method name is updated, etc.

Tools only give you the ability

noreply@blogger.com (Bob The Janitor) — Wed, 09 Jan 2013 06:33:00 +0000

Recently I read a post on the Alt.net linked-in group Would mocking help prevent these software bugs? talking about the Knight Capital Group Inc.’s disaster, asking the question "if doing more testing and using mocks would have prevented it?"

Doing unit testing with mocking is a tool, not a silver bullet. Unit tests mixed with behavior testing can be very effective at finding these kinds of bugs and Mocks allow you to create and test against foreseen conditions. While TDD can help expose bugs, unforeseen data conditions can pass though unnoticed, tests only test what they are told to.

Something else to keep in mind is behavior and unit tests are only a small part of the testing tool box that also includes: integration tests, performance tests, automated UI tests, etc. and that’s what these are tools. How effective they are depends on the user, a funny quote I once heard is “A tool runs tools, a craftsman uses them”. You can run your code coverage tool all day long and say “look I have 80% code coverage” but this doesn't mean your code is well tested, it just means it has test that run though it, and can hide untested code.

One commenter on the article said something to the effect that what they where working on requires to much performance to be testable. I would like to state this is B.S. you can make testable code that has just as much performance as not testable code. You may have to change how you test the code, or use different design or testing techniques for example Dependency Injection isn't required to make testable code, if it's not fast enough use greedy constructors or lazy load properties. If you need to make a black box class for performance, you simply do integration tests around it.

In the end, saying TDD isn’t of value because it didn’t catch bug xyz is like a carpenter blaming his hammer for hitting his thumb and not the nail. On the other side it’s just as ridiculous to say “I can build a house” simply because you own a hammer and some nails.

Keep contention out of collaboration

noreply@blogger.com (Bob The Janitor) — Wed, 17 Oct 2012 20:04:00 +0000

There is an old joke “arguing with a developer is like wrestling with a pig in mud, after a while you realizes he/she likes it”, and there are a number of reasons for this, as a group we tend to have strong options, stubbornness, know-it-all, and ego to name a few. Some of this is what makes us good developers, a lot of it is what makes us irrigating to other people.

I personally have been in my fair share of heated, angry, and down right nasty 'discussions' and in the past I may have been guilty of using the force of my will to get teams I have been on to do things 'The right way'. Even joking about being the “a-hole developer”, and as I matured as a professional, I realized even if I win like this, at what cost? I began to realize it was beginning to effect my health and that I didn't like who I was becoming.

We talk about the need to collaborate, from pair programming, sprint planning, daily stand ups, retrospectives, etc. but how often do they turn into arguments? Recently in the Javascript world there has been a lot of arguing about semicolons, and if they should be required. In all honesty this is really a non-problem, and yet people are getting brutal and down right offensive, over the need to be right? Being contentious will not change anyone’s mind, if there is a “winner” it’s because the other side has given up, and at what cost? Both sides are going to be resentful of the other, and it’s going to make working together that much harder.

This is not to say we can’t have discussions from different points of view, have different opinions, be a pushover, or not think the other side is off their rocker. Far from it, but we need to keep it civil and positive. Last I checked we (as developers) are paid to solve problems, not prove we are right. The heart of collaboration is taking different points of view and coming up with the best solution and we can’t do that if we are trying to prove we are right.

It’s ok to have strong opinions, I have more then a few, but it is also important be open minded, be willing to look at what the other side is saying, and come to an acceptable resolution on how to solve the problem. Admitting when you are wrong, or at least not completely right, can be very hard. Ultimately, be willing to work as a team, and if the team decides to do things “wrong” then that’s what the team wants. If you are working with a team that insists on doing things “wrong” and you are unable to contribute, then maybe this isn’t the team for you “If you can’t change where you work, change where you work”.

Running your test while you write them using NCrunch

noreply@blogger.com (Bob The Janitor) — Wed, 27 Jun 2012 08:01:00 +0000

A coworker told me about watching a presentation where the presenter used NCrunch, so I decided to take a look at it.

The basic idea is NCrunch automatically runs your tests in a parallel process giving you continuous testing that’s integrated into Visual Studio. It intelligently runs tests automatically so that you don't have to, and gives you useful information including code coverage and performance metrics while you work.

Here is an example of the inline test results

here is a screenshot of the test runner

and this what the coverage looks like

it’s not quite as detailed as I would like, but not bad.

This isn’t going to be a replacement for my copy of Resharper and DotCover but at the same time, I don’t see a problem with running both. This could defiantly save me a lot of time waiting for test to run and if I want more detailed information I can still use dotCover.

This is a free tool that so far has really impressed me, for more information go to the NCrunch home page athttp://www.ncrunch.net/

Testing for execution sequence

noreply@blogger.com (Bob The Janitor) — Mon, 25 Jun 2012 17:59:00 +0000

I ran into a problem the other day where I was doing some cost calculations and wasn’t getting the expected result, the problem turned out to be I was doing the calculations before everything got loaded, simple mistake.

Thought it would be interesting to show the solution I used for testing, lets say we have a simple method for updating an employee record.

public bool UpdateEmployee(EmployeeDto updateEmployee)
{
    var result = false;
    if(AuthRequests.UserCanUpdateEmployee(User.Id,updateEmployee.Id))
    {
        result = EmployeeRepository.UpdateEmployee(updateEmployee);
    }
    return result;
}

fairly simple, you call AuthRequests to see if the user and update the employee and then you update the employee. Here is an example test class for it

[TestFixture]
public class When_Updating_Employee_Information_Test: Test_Context<EmployeeRequests>
{
    public Mock<IAuthRequests> AuthRequestsMock;
    public bool ExpectedAuth;
    public int UserId;
    public int EmployeeId;
    public bool Actual;
    public bool Expected;
    public EmployeeDto UpdateEmployee;
    public EmployeeDto SentEmployee;
    public UserDto ExpectedUser;
    public Mock<IEmployeeRepository> MockEmployeeRepository;
  
    public override void Context()
    {
        base.Context();
        UserId = 12;
        EmployeeId = 14;
        Expected = true;
        ExpectedAuth = true;
        UpdateEmployee = new EmployeeDto{Id = EmployeeId};
        Target.User.Id = UserId;
        AuthRequestsMock = new Mock<IAuthRequests>();
        MockEmployeeRepository = new Mock<IEmployeeRepository>();
        
        AuthRequestsMock.Setup(x => x.UserCanUpdateEmployee(UserId, EmployeeId)).Returns(ExpectedAuth);
        MockEmployeeRepository.Setup(x => x.UpdateEmployee(It.IsAny<EmployeeDto>())).Callback<EmployeeDto>(
            x => SentEmployee = x).Returns(Expected);
  
        Target.AuthRequests = AuthRequestsMock.Object;
        Target.EmployeeRepository = MockEmployeeRepository.Object;
    }
  
    public override void Because()
    {
        Actual = Target.UpdateEmployee(UpdateEmployee);
    }
  
    [Test]
    public void Calls_AuthRequests_UserCanUpdateEmployee_Test()
    {
        AuthRequestsMock.Verify(x=>x.UserCanUpdateEmployee(UserId, EmployeeId), Times.Once());
    } 
  
    [Test]
    public void Calls_EmployeeRepository_UpdateEmployee_Test()
    {
        MockEmployeeRepository.Verify(x => x.UpdateEmployee(It.IsAny<EmployeeDto>()), Times.Once());
    }
  
    [Test]
    public  void Sends_expected_Emplyee_test()
    {
        Assert.AreEqual(UpdateEmployee.Id, SentEmployee.Id);
    }
  
    [Test]
    public void Returns_Expected_Result_Test()
    {
        Assert.IsTrue(Actual);
    }
}

the only problem is the tests still pass if the method looks like this

public bool UpdateEmployee(EmployeeDto updateEmployee)
{
    var result = EmployeeRepository.UpdateEmployee(updateEmployee);
    AuthRequests.UserCanUpdateEmployee(User.Id,updateEmployee.Id);
    return result;
}

so lets add some sequence tests, basically we add a counter and a dictionary<string,int> to record what was executed and it what order using the Moq callback.

   1: [TestFixture]   2: public class When_Updating_Employee_Information_With_sequence_Test : Test_Context<EmployeeRequests>   3: {   4:     public Mock<IAuthRequests> AuthRequestsMock;   5:     public bool ExpectedAuth;   6:     public int UserId;   7:     public int EmployeeId;   8:     public bool Actual;   9:     public bool Expected;  10:     public EmployeeDto UpdateEmployee;  11:     public EmployeeDto SentEmployee;  12:     public UserDto ExpectedUser;  13:     public Mock<IEmployeeRepository> MockEmployeeRepository;  14:     public int Counter;  15:     public Dictionary<string, int> Sequence;   16:    17:     public override void Context()  18:     {  19:         base.Context();  20:         UserId = 12;  21:         EmployeeId = 14;  22:         Expected = true;  23:         ExpectedAuth = true;  24:         UpdateEmployee = new EmployeeDto { Id = EmployeeId };  25:         Counter = 0;  26:         Sequence = new Dictionary<string, int>();  27:         Target.User.Id = UserId;  28:         AuthRequestsMock = new Mock<IAuthRequests>();  29:         MockEmployeeRepository = new Mock<IEmployeeRepository>();  30:    31:         AuthRequestsMock.Setup(x => x.UserCanUpdateEmployee(UserId, EmployeeId))  32:             .Callback(() => Sequence.Add("AuthRequests.UserCanUpdateEmployee", Counter++)).Returns(ExpectedAuth);  33:         MockEmployeeRepository.Setup(x => x.UpdateEmployee(It.IsAny<EmployeeDto>()))  34:             .Callback<EmployeeDto>(x =>  35:                  {  36:                     SentEmployee = x;  37:                     Sequence.Add("EmployeeRepository.UpdateEmployee", Counter++);
  38:                                        }).Returns(Expected);

  39:  
  40:         Target.AuthRequests = AuthRequestsMock.Object;  41:         Target.EmployeeRepository = MockEmployeeRepository.Object;  42:     }  43:    44:     public override void Because()  45:     {  46:         Actual = Target.UpdateEmployee(UpdateEmployee);  47:     }  48:    49:     [Test]  50:     public void Calls_AuthRequests_UserCanUpdateEmployee_Test()  51:     {  52:         AuthRequestsMock.Verify(x => x.UserCanUpdateEmployee(UserId, EmployeeId), Times.Once());  53:     }  54:    55:     [Test]  56:     public void Calls_AuthRequests_UserCanUpdateEmployee_Inorder_Test()  57:     {  58:         Assert.AreEqual(0, Sequence["AuthRequests.UserCanUpdateEmployee"]);  59:     }  60:    61:     [Test]  62:     public void Calls_EmployeeRepository_UpdateEmployee_Test()  63:     {  64:         MockEmployeeRepository.Verify(x => x.UpdateEmployee(It.IsAny<EmployeeDto>()), Times.Once());  65:     }  66:    67:     [Test]  68:     public void Calls_EmployeeRepository_UpdateEmployee_Inorder_Test()  69:     {  70:         Assert.AreEqual(1, Sequence["EmployeeRepository.UpdateEmployee"]);  71:     }  72:    73:     [Test]  74:     public void Sends_expected_Emplyee_test()  75:     {  76:         Assert.AreEqual(UpdateEmployee.Id, SentEmployee.Id);  77:     }  78:    79:     [Test]  80:     public void Returns_Expected_Result_Test()  81:     {  82:         Assert.IsTrue(Actual);  83:     }  84: }

for the full source see the sample application here.

Behavioral testing with NUnit

noreply@blogger.com (Bob The Janitor) — Wed, 20 Jun 2012 06:57:00 +0000

The traditional unit test works great for testing code functionality but another important testing aspect is testing code’s behavior and you don’t need to use a behavior testing framework like mspec to do it, with the right pattern nunit, mstest, and xunit work just fine.
A traditional TestFixture might look something like this

   1: [TestFixture]
   2: public class EmployeeRequests_Tests
   3: {   4:     private EmployeeRequests target;   5:     private Mock<IEmployeeRepository> MockEmployeeRepository;   6:     [SetUp]   7:     public void Setup()   8:     {   9:         target = new EmployeeRequests();  10:         MockEmployeeRepository = new Mock<IEmployeeRepository>();  11:         MockEmployeeRepository.Setup(x =>   12:             x.GetEmployeeByCityState(It.IsAny<string>(), It.IsAny<string>()))  13:             .Returns(new List<EmployeeDvr>  14:                {  15:                    new EmployeeDvr {City = "Seattle", State = "Washington", EmployeeName = "bob"}  16:                });  17:         target.EmployeeRepository = MockEmployeeRepository.Object;  18:     }  19:    20:     [Test]  21:     public void ReturnsErrorForEmptyCity_Test()  22:     {  23:         target.GetEmployeeByLocation(string.Empty, "Washington");  24:         var actual = target.Errors.Where(x => x.Contains("Invalid City"));  25:         Assert.AreEqual(1,actual.Count());  26:     }  27:    28:     [Test]  29:     public void ReturnsErrorForEmptyState_Test()  30:     {  31:         target.GetEmployeeByLocation("Seattle", string.Empty);  32:         var actual = target.Errors.Where(x => x.Contains("Invalid State"));  33:         Assert.AreEqual(1, actual.Count());  34:     }  35:    36:     [Test]  37:     public void VailidCityStateCallRepository_Test()  38:     {  39:         target.GetEmployeeByLocation("Seattle", "Washington");  40:         MockEmployeeRepository.Verify(x => x.GetEmployeeByCityState("Seattle", "Washington"));  41:     }       42: }

Having a fairly large TestFixture with a lot of tests for the different functions of the method being called.

When doing behavior testing the idea is to test a code path for a specific context vs. testing for all possibilities a method could result in, basically breaking it down into much easier to read parts.

To do this we set up a base or abstract class that has a context method for setting up your test and a because method for running it, here is an example of one using generics

[TestFixture]
public abstract class Test_Context<T> where T : new() 
{
    public T Target;
    
  
    [SetUp]
    public void Setup()
    {
        Context();
        Because();
    }
  
    public virtual void Context()
    {
        Target = new T();
    }
  
    public abstract void Because();
}

next we set up the the test fixture

[TestFixture]
public class When_Requesting_Employees_From_Seattle_Washington_Tests : Test_Context<EmployeeRequests>
{
    public Mock<IEmployeeRepository> MockEmployeeRepository;
  
    public override void Context()
    {
        base.Context();
        MockEmployeeRepository = new Mock<IEmployeeRepository>();
        MockEmployeeRepository.Setup(x => x.GetEmployeeByCityState("Seattle", "Washington"))
            .Returns(new List<EmployeeDvr> { new EmployeeDvr { City = "Seattle", State = "Washington" } });
        Target.EmployeeRepository = MockEmployeeRepository.Object;
    }
  
    public override void Because()
    {
        Target.GetEmployeeByLocation("Seattle", "Washington");
    }
  
    [Test]
    public void HasNoErrors_Test()
    {
        Assert.AreEqual(0,Target.Errors.Count);
    }   
 
    [Test]
    public void Calls_The_Repository()
    {
        MockEmployeeRepository.Verify(x=>x.GetEmployeeByCityState("Seattle","Washington"),Times.Once());
    }
}

a couple of things you may notice is first the the name is fairly long and descriptive, the idea is you want to make it easy to read the test results to know what your testing, in this case requesting employees from Seattle, WA.

The next thing you may notice is we don’t have as many test methods, sense we are only testing for what happens when we are getting employees from Seattle, WA. that’s all we are testing for. This may produce more test textures classes but at the same the test fixtures are more targeted and give a better description of what you are testing making it easier to read/maintain later and is sometimes called executable specifications, where you can find out the intended function of a class or method simply by reading then names for the test fixture and tests. For more examples of unit tests vs. behavoir tests see the sample application in the sample code repository.

Using description attribute class with enums

noreply@blogger.com (Bob The Janitor) — Mon, 30 Apr 2012 03:56:00 +0000

Enums are very useful way to make constant strongly typed replacements for magic numbers/string that are also self-documenting, the down side is they can be a little limiting, to solve this we can use class attributes and extension methods to get more out of them.

Adding a description to a Enum is fairly easy just use the System.ComponentModel.DescriptionAttribute class to add descriptions to the enum values

public enum BuildingTypes
{
    [Description("Retail Space")]
    RetailSpace=1,
    [Description("Office Space")]
    OfficeSpace=2,
    [Description("Single Family Residence")]
    SingleFamilyResidence=3,
    [Description("Multi Family Residence")]
    MultiFamilyResidence=4,
    [Description("Warehouse")]
    Warehouse =5,
    [Description("Manufacturing")]
    Manufacturing =6
}

In order to get the descriptions from the enum we need to do a little reflection and wrap it up in an extension method

public static string ToDiscription(this Enum value)
{
    var description = string.Empty;
    FieldInfo fi = value.GetType().GetField(value.ToString());
  
    var attributes = (DescriptionAttribute[])fi.GetCustomAttributes(typeof(DescriptionAttribute),false);
  
    if (attributes != null && attributes.Length > 0)
    {
        description = attributes[0].Description;
    }
    else
    {
        description = value.ToString();
    }
    return description;
}

Simple as that, for the full source see my sample code repository

Creating Custom Asp.net MVC ViewEngine

noreply@blogger.com (Bob The Janitor) — Mon, 26 Mar 2012 19:29:00 +0000

In the last post I talked about creating a custom ActionResult, the next question is, what if I want to add my a custom view engine? As an example lets say your company’s intranet uses multiple platforms (php, java, and now asp.net mvc) and to keep the look and feel constant you use xslt to render your header and footer, a simple solution is to add a xslt View Engine to generate the markup.

First you create a view to parse and output for content

public class XsltView : IView
{
    private readonly XslCompiledTransform _template;
  
    public XsltView(ControllerContext controllerContext, string viewPath)
    {
        _template = new XslCompiledTransform();
        _template.Load(controllerContext.HttpContext.Server.MapPath(viewPath));
    }
  
    public void Render(ViewContext viewContext, TextWriter writer)
    {
        var xmlDoc = viewContext.ViewData.Model as XDocument;
        if(xmlDoc==null)
        {
            var xs = new XmlSerializer(viewContext.ViewData.Model.GetType());
            xmlDoc = new XDocument();
            using (var xWriter = xmlDoc.CreateWriter())
            {
                xs.Serialize(xWriter, viewContext.ViewData.Model);
            }
        }
        _template.Transform(xmlDoc.CreateReader(),null,writer);
    }
}

then you create a view engine by inheriting from VirtualPathProviderViewEngine and override the CreatePartialView and CreateView methods to call your view

public class XsltViewEngine : VirtualPathProviderViewEngine
{
    protected override IView CreatePartialView(ControllerContext controllerContext, string partialPath)
    {
        return new XsltView(controllerContext, partialPath);
    }
 
    protected override IView CreateView(ControllerContext controllerContext, string viewPath, string masterPath)
    {
        return new XsltView(controllerContext, viewPath);
    }
}

to add the view open global.ascx.cs and modify the application start method to add the new view engine

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    ViewEngines.Engines.Clear();
    ViewEngines.Engines.Add(new WebFormViewEngine());
    ViewEngines.Engines.Add(new RazorViewEngine());
    ViewEngines.Engines.Add(new XsltViewEngine
        {
            ViewLocationFormats = new [] { "~/Views/{1}/{0}.xslt", "~/Views/Shared/{0}.xslt" },
            PartialViewLocationFormats = new[] { "~/Views/{1}/{0}.xslt", "~/Views/Shared/{0}.xslt" }
        });
    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
}

now to use it just add you xslt file to your view folder like you would with any other view and return your serializable object to the the View you’re returning

public ActionResult TransformedView()
{
    var model = new BasicDemoModel{Name = "Demo User"};
    return View(model);
}

for the full source (click here)

Creating Custom Asp.net MVC ActionResults

noreply@blogger.com (Bob The Janitor) — Sun, 25 Mar 2012 05:12:00 +0000

One of the most powerful things in Asp.net MVC is how easy it is to extend, a really good example is ActionResults. Basically all you have to do is inherit the ActionResult class and override the ExecuteResult method and add a constructor, with a few lines for code you can have an action return anything you want from dynamically generated pdf and xls files, to images.

Here is an example of returning an object as xml

public class XmlResult : ActionResult
{
    private readonly object _item;
  
    public XmlResult(object item)
    {
        _item = item;
    }
  
    public override void ExecuteResult(ControllerContext context)
    {
        if (_item != null)
        {
            var xs = new XmlSerializer(_item.GetType());
            context.HttpContext.Response.ContentType = "text/xml";
            xs.Serialize(context.HttpContext.Response.Output, _item);
        }
    }
}

basically you pass the object you want serialized into the constructor, and return it. Inside the ExecuteResult method I do a quick null check, spin up a XmlSerializer set the response content type to “text/xml” and use the HttpContext.Response.Output to write the serialized data.

All you have to do to use it is create a new instance and return it from your action

public ActionResult Index()
{
    var model = new BasicDemoModel();
    return new XmlResult(model);
}

To see the code used checkout the sample application at here.

Automated Builds and Continuous Integration with Jenkins

noreply@blogger.com (Bob The Janitor) — Thu, 19 Jan 2012 19:50:00 +0000

The concept of an automated build is fairly basic, you simply take your existing build file (make, nant, ant, msbuild(.sln), rake) and set up a service to build it from your source control repository.

Automating builds

Setting up automated builds provide a number of advantages:

Everything your project needs to build and run is checked into source control.
By scripting your builds you remove human error problems, computers are just better at running repetitive tasks
Logging what was done and when it was done.

At a former employer the marketing department needed to do content updates on a fairy regular basis; So they wouldn’t have to wait for us, I set them up with svn for the content directory and created some users for content deployment. All they had to do was update the content and commit it and then deploy it. We where happy because we didn’t need to spend time on their deployments, and they where happy because they could push content any time they wanted to.

Continuous Integration

This is a key part of doing Test Driven Development, making sure your tests are run when checked in. This makes sure that all of the tests are working in the build environment, and lets everyone know when there is a problem as soon as the build runs, and lets the developer responsible to fix it as soon as possible, creating an over all better code quality.

Using Jenkins

Jenkins is an open source Build server forked from the Hudson project, basically when Oracle bought Sun/Java some of the Hudson team decided to was time to go their own way. Jenkins Benefits from a log history of community support from it’s Hudson days allowing it to be a very mature and extendable system. Having said that, it not as easy to use as some other build servers (see Continues Integration with TeamCity) but what it lacks in ease of use, it makes up for in versatility and flexibility.

User Management

Like most things in Jenkins User management is very flexible by default supporting LDAP, it’s own internal user DB, delegate to servlet container, and has a huge list of user management plug-ins for everything from Active Directory to GitHub OAuth. Once the user is added you also have a fairly flexible authorization set up from allowing anyone to do anything to completely locking it down.

My biggest complaint here is that by default everything is wide open and the responsibility of locking everything down is placed on the administrator.

Build Jobs

By default Jenkins supports Maven2/3, completely rolling your own multi part build, and Monitoring an external job but with a large selection of plug-ins supporting everything from rake to powershell to Fitness, to an Android Emulator.

Rolling your own multi part build is fairly strait forward if a little involved with a lot of the basic options you would expect like wither to keep old builds, how long do you want to keep them, how many do you keep, Quiet period, retry count, etc.

With it’s plug-ins your source control provider options are just about anything you can think of including:SVN, CSV, Git, ClearCase, etc. The same for build triggers by default it supports build after other projects, build periodically(nightly builds for example), pull scm, and remote triggering(call a url with an auth token to start a build).

When your done with your build you have built in support to ftp or ssh your build results with plug-ins to do everything from upload to Amazon S3 to the Appaloose Store for mobile apps.

The down side to all of this flexibility is you are forced to do a lot for the configuration your self, unlike TeamCity, if you want your code test results published you have to configure it yourself, if you want your code coverage results, you have to configure it to use something like PartCover yourself.

Reporting

Just as important as automating your builds is knowing what is going on with them, when are they running, did it fail, what failed, etc. Jenkins has fairly nice tools built in to show you what is going on. With a build history trend report, rss feeds, Email notification, and plug-ins to support everything from dashboard views to creating a Wall friendly display of all build jobs.

Conclusion

While not as nice to set up and manage as some other build servers, Jenkins is incredibly powerful with a lot of flexibly, and to be honest it’s really hard to complain about an enterprise level build server for free. I would make the comparison between running Linux VS. Windows servers, Windows may be more polished but it’s not as flexible.

Finally decided to do a dev tools list

noreply@blogger.com (Bob The Janitor) — Mon, 09 Jan 2012 05:28:00 +0000

One of the most important parts of being a craftsman is your selection of tools, it doesn’t matter if you are a carpenter, a mason, cabinet maker, or even a software developer, your tools allow you to get the work done. What tools you use really depends on your style and technique and may very greatly depending on the person. This is a simple list of IDEs, editors, libraries, etc. that I like and work for me, some are pay for, most are not. This isn't a complete list of the tools I use but it's a good solid overview of what I use on a day to day basis, take a look and see what you like, or don’t.

IDEs

Visual Studio 2010 – The default editor for doing .NET development, it has it’s share of problems but for the most part it a very sold IDE.
MonoDevelop – This is where .NET started for me 8 years ago, not a lot of frills, but for a fully functional cross platform IDE for .NET the price is right at free, unless you want to do Android or IOS, then you need to buy monoDroid or monoTouch.
NetBeans – My go to java and PHP IDE, with good intellisense and built in refactoring tools.

Visual Studio Plugins

Resharper – The most valuable IDE plugin I have ever used, providing nUnit support, refactoring, add reference, and the list keeps going. I honestly have a hard time using Visual Studio with out it.
DotCover – An important part of test driven development is code coverage, and DotCover is my coverage tool of choice. It integrates with Resharper’s test runner to provide on request code coverage in the IDE.

Source Control

AnkhSVN – Provides SVN support for Visual Studio, so far this is the best free SVN plugin I have found for Visual Studio
Visual SVN server – A simple and easy SVN server that just works, it may not have a lot of bells and whistles but it’s easy to install and manage users.

Text Editors

Notepad++ – One of the first things I do on any new windows system is install Notepad++, it integrates with Windows explorer making it simple to edit any text file with out having to deal with what the default app is for the ext. with a huge list of plugins for everything from XML to powershell it is the Swiss Army Knife of text editors.

SQL Tools

Toad For SQL Server – This is a new item on my tools list, I just started using it this week, but I really like it. The community version has some really nice intellisense, and the way the UI works is just clean. I’m really interested in seeing a head to head comparison between Redgate’s SQL Tool belt and Toad Development Suite for SqlServer, the features look about the same, but at around $1,300 vs. $2,000 toad is a lot cheaper.
FluentMigriator – A .NET version of the Ruby Migrations tool. With a fairly simple syntax and helpers it makes scripting DB changes easy, to read more check out this blog post I did a little while ago, Using Fluentmigrator with nant.

Unit Testing

NUnit – The work horse of the .NET unit testing world. It’s a solid testing framework with some of the best tool support out there, with the exception if Visual Studio, but Resharper fixes that.
Moq – The Simplest mocking framework for .NET. With a clean fluent syntax that provides ease of use and versatility.

Build And CI Server

Team City – By far the easiest to get set up and start running with. With built in support for most of the tools I use and has DotCover built in, it provides a solid solution out of the box with a very polished UX.
Jenkins – A fork of the Hudson project, Jenkins is a solid if less then polished build and CI server solution, but what it lacks in polish it makes up in versatility and flexibility, with a huge selection of plugins for integrating into just about development environment and deploying to just about any other system out there.

Test Driven Development for the management point of view

noreply@blogger.com (Bob The Janitor) — Thu, 05 Jan 2012 21:09:00 +0000

When I have given presentations on TDD, one of the biggest questions I get is “How do I sell this to my boss?”, and it’s a very valid question, you are basically asking your boss to let you write 2-3x as much code to make sure the code you wrote is correct, that’s a tough sell all on its own. Software can never be done soon enough, most projects are already behind from the start, and now you want to take more time to write more code?

Time is Money

There is a cost to Test Driven Development (TDD), you are doing more work, writing tests takes time, maintaining tests takes time, and running tests takes time. With time equaling money the question is “what are you buying?”, the simple answer is security, and long term cost reduction.

Ever wonder what it would be like to have a car without a check engine light? For the most part it’s something most of us never look at. When it turns on we take it to the shop and the mechanic fixes whatever is wrong. Without the check engine light to tell you something is wrong, what could have been a small repair is now an engine rebuild. Having tests provides you with the same thing, it lets you know there is a problem before it becomes a larger problem, this could be inconsistent application behavior, data corruption, or the application crashing.

Real world example

At a former employer we were migrating to a new production database for our flagship application, the database it’s self was a very complex system, lots of tables, triggers, stored procedures, etc. The DBA migrated the schema to the new server, got a snapshot of the data and then ran our integration tests and had failures everywhere, invalid permissions, missing columns, etc. Even using the failed tests as a road map to took the DBAs 1 ½ days to fix all of the problems. I can’t even guess how long it would have taken to fix if we would have just done to production, on top of that the company’s main product would have been down, not only affecting us, but also all of our customers that depended on our product to run their businesses.

We Could have just blamed the DBA for not getting everything right the first time, but at the same time, how much time was he given to do it, would it have been cost effective to spend more time for this one time, verses spending the time writing tests that can test it over and over again.

Spending a little to save a lot

Software bugs have costs: they cost to find, they cost to track, they cost to fix, they cost to verify when fixed, and they cost to push out the fix.

Cheap - A developer finds a bug when it was written, he/she fixes it, very little cost
More Expensive - QA finds the bug, the tester needs to make sure it’s an actual bug, retest to verify how to reproduce it, then records it a bug report, sends the bug report to the developer, the developer fixes the bug, send the fix back to QA, it’s retested, then the bug report is closed.
Very Expensive – User finds bug, contacts customer service, customer service sends bug to QA, QA verifies the bug, creates a bug report, developer fixes bug, sends the fix to QA, QA verify bug is fixed, bug fix is redeployed to production.

How much the bug costs depends on how soon it’s discovered, the sooner it’s discovered, the less people touch it and the less it costs. By writing tests developers are far more likely to find bugs sooner also nothing is more frustrating than having bugs reappear, manually retesting existing functionality takes time, and increases QA cost, also reduces the time QA has to find new bugs, and edge case bugs. TDD inherently provides regression testing and can greatly reduce your QA time.

Real world example

At one time I worked as a QA Engineer at a major printer company, a little over half my time was spent not only testing new functionality, but existing functionality as well, the rest of my time was spent sending bug reports to the developers, having the developers asking for clarification, verifying the bug was fixed, etc. As much as it cost for me to test a printer, the cost of having a driver or even worse a firmware bug get released to the customer where astronomical. By reducing the time I had to spend retesting and verifying bugs, I could spend more time looking for edge case bugs.

Something else to think about is unlike web development where you are only pushing code to your servers, having hardware in the hands of consumers with a bug requires the added cost of service representatives, service techs, etc.

Reducing Costs by building on a well build foundation

TDD by it nature encourages good development practices, by breaking up chunks of code into more testable sections, you are turning them into more manageable pieces; this reduces the amount of time and effort required to update and maintain your application and greatly reducing the need for the dreaded rewrite.

Ask any construction contractor what makes the biggest difference on a building remodel, and they are probably going to tell you “How well the original building was built”. If the foundation isn't level or the walls aren't straight, it’s going to make his job that much harder having to compensate for the existing structure. The same thing applies to software development, the less old code that needs to change to add new features, the less it costs to add new feature with the added bonus of the tests telling you where your changes affect the rest of the application.

Real world example

I worked on a project that was needed to replace how users authenticated; the user still entered a user name and password, but how they were verified need to be updated for security reasons. By having the application broken up, all that needed to be changed is adding the new authentication code and changing one line in the existing code to implement the new functionality.

Using TDD isn't required to use these best practices, but trying to do TDD without using them is painful to next to impossible.

More Ajax with MVC – Using Partial Views with Ajax

noreply@blogger.com (Bob The Janitor) — Sun, 27 Nov 2011 10:55:00 +0000

One the the really nice features in asp.net mvc is the ability to use partial views, not only for breaking up pages and reusing content but also for doing Ajax calls. In Easy Ajax with ASP.NET MVC and jQuery I showed you how to do a basic Ajax call and display the data returned, now I’m going to show you something a little more useful, actually retuning content to display on the page.
First we take this partial view

@using SampleApplication.Models
@model PartialModel
  
<div>
    @Model.Text
</div>
<input type="button" value="click me" onclick="UpdateView();return false;"/>

Then we add it to the main view like this

<div id="UpdateableContent">
    @{ Html.RenderPartial("Partial",new PartialModel{Text = "Before Clicked"}); }
</div>

Next we need to have a Action to call that returns the rendered view with updates

public ActionResult UpdatePartial()
{
    var model = new PartialModel() {Text = "was updated"};
    return View("Partial", model);
}

In this case we update the model and return the specified partial view with the updated model.

Last we have the Javascript that makes the Ajax call

   1: function UpdateView() {

   2:     var model = { };

   3:     $.post("/home/UpdatePartial",

   4:         model,

   5:         function (data) {

   6:             $("#UpdateableContent").html(data);

   7:         });

   8: }

it’s fairly simple and a lot like what we did in the Easy Ajax post, the major difference is we take the returned rendered partial view and replace the existing rendering of the partial view using JQuery’s .html(), this replaces the existing content with the passed in content. This is a very simple and effective way to manipulate your pages.

As always here is the source code for a sample project using it

Using FluentMigrator with nAnt

noreply@blogger.com (Bob The Janitor) — Sun, 17 Jul 2011 05:38:00 +0000

On a project I was working on a while ago, we all had local copies of the DB in versioned .sql files, and then every time we did an update we would run the sql in the DB files and hope it build the DB.
More often then not it would blow up and so I would spend the first 1/2 hour every time I worked on the project getting things to work again. Well no more!
FluentMigrator is based on Ruby Migrations, with a fairly simple syntax. The db classes have the attribute [Migration()] that specifies the version, and inherit from the Migration class, and override the two methods Up and Down.

   1: [Migration(20110624232410)]   2: public class AddUserTables : Migration   3: {   4:     public override void Up()   5:     {   6:         Create.Table("Users")   7:             .WithColumn("Id").AsInt32().Identity().NotNullable()   8:             .WithColumn("Name").AsString().NotNullable()   9:             .WithColumn("Password").AsAnsiString().NotNullable();  10:     }  11:    12:     public override void Down()  13:     {  14:         Delete.Table("Users");  15:     }  16: }

Migrating Up and Down

The Reason for the Up and Down methods is very simple; if the version your migrating to is higher then the version of this class it executes the code in the Up method and if the version is lower then the code in the Down method executes. Basically whatever you do in the Up is undone in the Down.

Setting The Version Number

Something else you may have noticed is in the Migration tag the version number is fairly large, to make versioning easier on a team, I’m not using consecutive numbers but the date and time(using 24 hour time) of when the I added this class, so the the example class I created was on 6/24/2011 at 23:24 10. The current version number is also stored in the DB, making it very simple to see what DB version you’re on, this can come in handy if your code is based on a specific DB version you can do a simple check to see if you have the correct DB version.

Keeping version iterations small

Just like when creating a business logic class, you should follow the single responsibility principal, and have each class do only one thing, this may mean having a lot of classes but on the other side it will make it a lot easier to keep track of what each version added, modified, or removed.

Adding stuff to the Data Base

Using the Fluent api allows you to very smoothly add tables, columns etc. in a very readable way. If you look at the Up method in the above example you can see how easy it is to add a table with columns. This makes it very easy to add your own extension methods to short had it even further. Here is an example for creating an identity column and a table with time stamps:

   1: internal static class MigrationExtensions   2: {   3:     public static ICreateTableColumnOptionOrWithColumnSyntax WithIdColumn(this ICreateTableWithColumnSyntax tableWithColumnSyntax)   4:     {   5:         return tableWithColumnSyntax   6:             .WithColumn("Id")   7:             .AsInt32()   8:             .NotNullable()   9:             .PrimaryKey()  10:             .Identity();  11:     }  12:    13:     public static ICreateTableColumnOptionOrWithColumnSyntax WithTimeStamps(this ICreateTableWithColumnSyntax tableWithColumnSyntax)  14:     {  15:         return tableWithColumnSyntax  16:             .WithColumn("CreatedAt").AsDateTime().NotNullable()  17:             .WithColumn("ModifiedAt").AsDateTime().NotNullable();  18:     }  19: }

But the api doesn't have everything you need so you have the option of adding in strait sql using Execute.Sql(). like this example:

   1: Execute.Sql("DELETE FROM `Users` WHERE Name = 'TestUser'");

also you can call sql files like this:

   1: Execute.Script("myscript.sql");

Adding Data

The next step is to add some data. This could be some sample data for development, a larger dataset for QA, QA data for a specific type of customer, or base data for production. By adding profiles you can abstract away what data you want to add for specific function. This is not where you add data for things the should be constant, things like lookup tables should be handled by a versioned migration class. Here is an example of a profile class:

   1: [Profile("Development")]   2: public class DevelopmentProfile : Migration   3: {   4:     public override void Up()   5:     {   6:                7:         Insert.IntoTable("Users").Row(new {Name = "TestUser", Password="12345"});   8:     }   9:    10:     public override void Down()  11:     {  12:         Execute.Sql("DELETE FROM `Users` WHERE Name = 'TestUser'");  13:     }  14: }

Just like a Version class it inherits from the Migration class and has an up and a down method, this way when you add one profile it will remove the other profiles.

Deploying/Migrating Your Data Base

Deploying or Migrating your data can be done with a console app or with a build runner like MSBuild, nAnt, or Rake making it easy to integrate into your existing build process. For this example we are going to use nAnt. Here is an example nAnt build file:

   1: xml version="1.0" encoding="UTF-8" ?>   2: <project name="FluentMigratorProof" xmlns="http://nant.sourceforge.net/release/0.90/nant.xsd" default="migrate-Production">   3:   <loadtasks assembly="./FluentMigrator.NAnt.dll" />   4:   <target name="Reset" description="Migrate the database to the base version">   5:     <migrate   6:     database="sql"   7:     connection="Data Source=DevBOX\SQLEXPRESS;Initial Catalog=FluentMigratorProof;User Id=BuildUser;Password=xxxxxxx;"   8:     namespace="FluentMigratorProof"   9:     target="./FluentMigratorProof.dll"  10:     task="rollback:all"  11:     />  12:   target>  13:   <target name="migrate-Production" description="Migrate the database to the latest version">  14:     <migrate  15:     database="sql"  16:     connection="Data Source=Production\SQLEXPRESS;Initial Catalog=FluentMigratorProof;User Id=BuildUser;Password=xxxxxxx;"  17:     namespace="FluentMigratorProof"  18:     target="./FluentMigratorProof.dll"  19:     profile="Production"  20:     />  21:   target>  22:   <target name="migrate-Development" description="Migrate the database to the latest version">  23:     <migrate  24:     database="sql"  25:     connection="Data Source=DevBOX\SQLEXPRESS;Initial Catalog=FluentMigratorProof;User Id=BuildUser;Password=xxxxxx;"  26:     namespace="FluentMigratorProof"  27:     target="./FluentMigratorProof"  28:     profile="Development"  29:     />  30:   target>  31: project>

To use FluentMigrator with nAnt you use loadtask to specify the FluentMigrator.dll then you add a migrate task in your target. Your migrate task will need to have the following properties:

database – this specifies the type of DB (sql, oracle, sqllight, mysql, etc.)
connection – this specifies the DataBase your going to connect to and with what permissions
namespace – this is the application namespace your going to run allowing you to migrate multiple DB in the same project
target – this is the .Dll you’re calling to migrate from
Profile – this is what profile your loading
task(optional) – this is how you specify what version you want to build, or if you want to roll back, etc.

Then to run your migration simply run NAnt.exe with the name of your build file something like:

   1: NAnt.exe -buildfile:ProofBuild.nant.build

A full explanation of using nAnt is a little out of scope for this blog post so if you want more info on nAnt see nAnt Help Page.

As always here is a sample project using this.

Where is the passion?

noreply@blogger.com (Bob The Janitor) — Thu, 14 Jul 2011 06:03:00 +0000

On the 4th of July I had a really good conversation with @jamis a former member of the rails core team and a fairly prominent member of the ruby community and I was reminded how much the Ruby community appers to be more dedicated to craftmanship then the .net community as a whole.

This may be just an outsiders view but ruby devs seem to be more dedicated to pair programing, TDD, CI, etc. and basicly more interested in writing software to make a living vs. where in the dot net comunity it feels more like developers write software just to make a living, there are a few leaders that that push these ideas, but for the most part it seem more previlant in the ruby community.

So my real question is, why? is the ruby stack just more attractive to people of this disposion? is it just becouse dot net is just more widely used and thus just has a wider spectrum of developers in it? Is it just becouse I have a very limmited view of the ruby community and only seeing the cream of the crop, or am I just somewhat jaded and only seeing the negative in the .net community? To this I don't have a good answer.

So the next question is how do we get the passion in the .NET dev stack? it's not like there is a lack of interesting things to learn and build, can we do more community work? Boise has a .NET user group (netdug), a software developers group(bsdg) that is mostly .net developers, and a code camp every year, but for the most part it's the same people group presenting. my open question to the group is how do we get more people interested in presenting, do we start younger? maybe start youth dev groups? maybe as a group pressure each other to be more active? For my part, I need to step up and do my part, and rededicate myself to blogging.

Decoupling to Destruction

noreply@blogger.com (Bob The Janitor) — Mon, 23 May 2011 14:02:00 +0000

One of the core concepts of well architected code is being decoupled, but like so many of the good things in life if you do it to much it becomes bad for you.

Recently I worked on a piece if legacy code that from the UI to the Dal it passed an object though 7 classes and was converted from one object to the next 5 times. Their wasn’t any real difference from one object to the next. In some cases it was pulled from the data object and each item was passed as a parameter into a method where it was then put into a new object. The result was next to imposable to debug, even harder to read, and in a lot of places just plain sloppy.

In an earlier post N-Tier Design Revisit part 2 – Data Entities I talked about how data entities, poco, or dto (they are all basically the same thing more or less) work, they go from the UI though the Biz and to the Dal and back again. This creates a message that is passed, your code is still decoupled because the Data Entity basally contains no logic, it’s just holding data.

Wring an application is kind of like growing a garden, if you take care of it and maintain it, it stays nice and easy to maintain. If you neglect it it becomes difficult to maintain and will over time die. Decoupling is one of the things you do to make it easy to maintain your application, kind of like watering it, and just like watering it if you do it to much you’ll kill it.

The janitor's closet

Boise Code Camp Presentation on Into to Continues Integration

Slides from my Into to TDD talk at Boise Code camp

Unit Testing Asp.net MVC View Model Validation

I agree With Apple and San Bernardino County is at fault

Enterprise Design Patterns and Practices (Boise Code Camp 2015)

Fundamental principals

S.O.L.I.D. Principals

Be strongly typed and loosely coupled

The 2 biggest problems you will face

Golden Hammer

Silver Bullets

Automation, Automation, Automation

Build server & source control

Application Deployment

Database Deployment/Migration

Testing

Instrumentation

Logging

Memory Profiler

Site monitoring and Analytics

Leveraging 3rd party tools

Abstract your 3rd party includes

Building for Extendibility

n-Tier Design

DTO, POCO, and Model objects

Separate Update, Select and Work Logic

Do not over abstract

Building for Scalability

Caching

Spreading the Load

Queuing up

CDN (Content Delivery Network)

Not everything needs to go to the DB or come from it

Redundancy

Boise Code Camp 2014

Testing un-mockable base class methods

Steps for shortening the “Feedback Loop”

Step 1: Short Development Iterations

Step 2: Work in Small Teams

Step 3: Test Driven Development

Step 4: Continuous Integration

Step 5: Automate as much as possible

Death by Golden Hammer

Having the right tools can make all the difference

Tools only give you the ability

Keep contention out of collaboration

Running your test while you write them using NCrunch

Testing for execution sequence

Behavioral testing with NUnit

Using description attribute class with enums

Creating Custom Asp.net MVC ViewEngine

Creating Custom Asp.net MVC ActionResults

Automated Builds and Continuous Integration with Jenkins

Automating builds

Continuous Integration

Using Jenkins

User Management

Build Jobs

Reporting

Conclusion

Finally decided to do a dev tools list

IDEs

Visual Studio Plugins

Source Control

Text Editors

SQL Tools

Unit Testing

Build And CI Server

Test Driven Development for the management point of view

More Ajax with MVC – Using Partial Views with Ajax

Using FluentMigrator with nAnt

Migrating Up and Down

Setting The Version Number

Keeping version iterations small

Adding stuff to the Data Base

Adding Data

Deploying/Migrating Your Data Base

Where is the passion?

Decoupling to Destruction

Leveraging 3^rd party tools

Abstract your 3^rd party includes