Mark Brown from Microsoft shows the Web Platform Installer, a free tool from Microsoft to get fresh Windows machines up and running for web developers with an array of free tools and websites.

In this article I will explain accessing OLAP Server Data with ADO .NET.

In this article I will explain about MIME Types.

In this article I will explain you about a named permission set in C#.

In this article the author explains how PSModuleInfo object for a module can be retrieved. Further, he shows how code can be injected into the module to manipulate the state of a module without having to reload it. He also explains how to directly set some metadata elements, like the module description, and some other PSModuleInfo object features.

Rating Control is introduced in WPF Toolkit February 2010 release. In this article we will see how we can use the Rating Control.

I once posted a semi-serious post entitled The 7 Phases of Unit Testing. The phases are:

1. Refuse to unit test because "you don't have enough time"
2. Start unit testing and immediately start blogging about unit testing and TDD and how great they are and how everyone should do it
3. Unit test everything - make private methods internal and abuse the InternalsVisibleTo attribute. Test getters and setters or else you won't get 100% code coverage
4. Get fed with how brittle your unit tests are and start writing integration tests without realizing it.
5. Discover a mocking framework and make heavy use of strict semantics
6. Mock absolutely everything that can possibly be mocked
7. Start writing effective unit tests

I think the cycle I went through is extremely healthy - unit testing is something best learnt from practice and is something you refine over time. Judging by the comments on the original post, a lot of you agree.

Recently though, I've felt like adding another stage:

8 . Sometimes the best tests aren't unit tests

After awhile, it becomes obvious that some tests are significantly more meaningful when you expand your scope - say to include hitting an actual database. Narrow unit tests and wider integration tests can always work together; but I've found that, in some cases, more comprehensive tests can replace corresponding unit tests. This may not be a proper, but it is practical.

When I say unit test, I mean the smallest possible unit of code - generally a behavior. Most methods are made up of 1 or more behavior. I'd say that you shouldn't have too many methods with more than 6 behaviors (as a rough goal). As an obvious example, in NoRM this method helps identify the type of the items in a collection:

public static Type GetListItemType(Type enumerableType)
{
    if (enumerableType.IsArray)
    {
        return enumerableType.GetElementType();
    }
    if (enumerableType.IsGenericType)
    {
        return enumerableType.GetGenericArguments()[0];
    }
    return typeof(object);
}

Clearly, this method is a good candidate for 3 or 4 unit tests (one when the type is an array, one when it's a generic, one when its something else, and maybe one when its null).

As your code moves closer to the boundaries of 3rd party components, the value of unit testing may suffer. You'll still get the benefits of flushing out coupling and enabling safe refactoring (which shouldn't be underestimated), but you'll likely miss out on making sure things will work like they should in production. The solution can be to expand the scope of your tests to include the 3rd party component.

The most common example is database code. Testing a Save method by mocking the underlying layer might work, but there's value in making sure that the object actually does get saved. That isn't to say that a single test that hits the database is good enough - your Save method might be made up of multiple behaviors, some which are better validated with one form of testing than another.

Really, that's one of the key things to remember as you walk down this path - don't think that just because your method is actually saving an object that your job is done. There are likely other behaviors that aren't being tested at all. It's easy to abuse these types of tests and get a false sense of security. The other key is to make sure that it runs like a unit test - namely, that its fast, doesn't require any manual setup, and isn't dependent or doesn't break any other test.

Lately, I've seen interest in using in-memory databases for this type of thing. The benefit is that they are super fast and don't leave stale data. They also don't require special setup. On the downside you still aren't truly testing the most fundamental behavior of your method - that an object will be saved to the database in production. Even with the best O/R tool I've seen code work against one database but not work against another - due to a bug on my part. Writing a script that can automatically and quickly setup and teardown against the final database, and having your team members set up a local database, may or may not work for you (it'll depend on the nature of your team and your system).

Ultimately, the most important thing is that you have automated tests which aren't a nightmare to setup, maintain or run. Integration tests have more dependency and thus are more fragile, but can be an efficient way to verify correctness.

In Part II of this article series we have seen the concepts of Commands and we experienced Command Binding feature. In this article we will see how Input Binding is helpful.

In Part I of this article series we have seen the basics of using Commands. In this article we will explore more on that.

Just a quick run by posting from some discussions yesterday. I see many people using the State Pattern in their domains. More often than not though they are making a mistake that can be seen by analyzing the OO aspects of their code. Let’s go through a quick example of a Loan Application.

 

When its “In process” you can edit data on it or submit for approval.

When its “awaiting approval” you can no longer edit details data but you can approve or deny the application.

When its “completed” it has become immutable and can no longer be edited but may have some getters on it for viewing of historical data

 

I went through and made a quick little example of this

public interface ILoanApplicationState
{
    void Approve();
    void Deny();
    InterestRate GetApprovedInterestRate();
    InterestRate CalculateLikelyInterestRate();
    void SubmitForApproval();
    void ChangeDetails(LoanDetails details);
}

public class LoanApplicationState : ILoanApplicationState
{
    private LoanApplication parent;
    public LoanApplicationState(LoanApplication Parent)
    {
        parent = Parent;
    }

    public virtual void Approve() {}
    public virtual void Deny(){}
    public virtual InterestRate GetApprovedInterestRate() {}
    public virtual InterestRate CalculateLikelyInterestRate() {}
    public virtual void SubmitForApproval(){}
    public virtual void ChangeDetails(LoanDetails details) {}

}

public class InProcessState : LoanApplicationState
{
    public InProcessState(LoanApplication Parent) : base(Parent) { }

    public override void Approve()
    {
        throw new InvalidOperationException("Cannot approve an inprocess application");
    }

    public override void Deny()
    {
        throw new InvalidOperationException("Cannot deny an inprocess application");
    }

    public override InterestRate GetApprovedInterestRate()
    {
        throw new InvalidOperationException("No approved interest rate exists on an in process application");
    }

    public override InterestRate CalculateLikelyInterestRate()
    {
        return InterestRate.Default;
    }

    public override void SubmitForApproval()
    {
        //change parent state to submitted
    }

    public override void ChangeDetails(LoanDetails details)
    {
        //change parent details
    }
}

public class AwaitingApprovalState : LoanApplicationState
{
    public InProcessState(LoanApplication Parent) : base(Parent) { }

    public override void Approve()
    {
        //change parent state to approved and issue some behavior
    }

    public override void Deny()
    {
        //change parent state to denied and issue some behavior
    }

    public override InterestRate GetApprovedInterestRate()
    {
        throw new InvalidOperationException("No approved interest rate exists on an awaiting approval application");
    }

    public override InterestRate CalculateLikelyInterestRate()
    {
        return InterestRate.Default;
    }

    public override void SubmitForApproval()
    {
        throw new InvalidOperationException("Already awaiting approval");
    }

    public override void ChangeDetails(LoanDetails details)
    {
        throw new InvalidOperationException("No approved interest rate exists on an in process application");
    }
}

public class CompletedApplicationState : LoanApplicationState
{
    public InProcessState(LoanApplication Parent) : base(Parent) { }

    public override void Approve()
    {
        throw new InvalidOperationException("Application has already been completed");
    }

    public override void Deny()
    {
        throw new InvalidOperationException("Application has already been completed");
    }

    public override InterestRate GetApprovedInterestRate()
    {
        //return parents approved interest rate
    }

    public override InterestRate CalculateLikelyInterestRate()
    {
        //return parents approved interest rate
    }

    public override void SubmitForApproval()
    {
        throw new InvalidOperationException("Already completed");
    }

    public override void ChangeDetails(LoanDetails details)
    {
        throw new InvalidOperationException("Application is already completed");
    }
}

 

 

OK enough yucky code you guys get the idea (the state pattern is also very verbose). The idea here is we plug in these state objects to our object and they handle the behavior changes from the original object.

My contention here is that you should not use the State Pattern like this. Where is the polymorphism? What if we think about the gross violation of LSP that we just created? This does however happen way too often.

The solution is that we really have three classes here InProcessApplication, AwaitingApprovalApplication, and CompletedApplication.

public class InProcessApplication {

    InProcessApplication SubmitForApproval(ILoanProcessingService processor) { …  }

}

this will force us to end up with smaller and easier to understand classes… and I mean hey, its not like polymorphism would have worked before anyways. It also makes our Ubiquitous Language more concise.

There is a particular code smell here that will help us distinguish whether we want the State Pattern or separate classes. Do some of the data/behavior only make sense in certain states? If so use three separate classes. Going along with this, if we find “throws” in our state implementors we should realize through LSP that we are doing something bad.

In this article we will see what Commands are and how we can use them in WPF.

In this article, I want to explain the new features of Visual Studio.NET 2008 and JDeveloper 11g which are the IDE provided by Microsoft and Oracle for the development of enterprise application for .NET and Java platform.

In Part I of this article series we have seen some features available to Silverlight 4 with VS 2010. We will continue to explore more in this article.

In this article I will explain Creating Your First ADO.NET Web Application.

In this article we will see what we can achieve in Silverlight 4; which is not possible or partially possible in Silverlight 3.

In this article I will explain about Encoder Parameters and Image Formats in GDI+.

In this article, I am going to show, how we could achieve grouping in LINQ to object.

In this article I will explain you about the Security Policy Levels.

Page Methods is a new mechanism in ASP.NET applications where the server code can be bound to ASP.NET pages. It is an easy way to communicate asynchronously with the server using ASP.NET AJAX technologies. It is an alternate to calling the page which is reliable and carries a low risk. It is basically used to expose the web methods to the client script.

This Thursday, I’ll be joining John Bristowe and Joey Devilla to talk about composite applications, patterns, MEF and anything else that comes up. I am flexible :-)

This is a live webcast where questions will be taken in real time, so ask away! I am selfish but no slides or demo prep sounds great to me!

Register here: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032439322&Culture=en-CA