Automated Testing a WCF Service

Slightly, ok very, off topic but this is something I've been working on today and I need to blog about it before I forget what I did!

I need to create a test harness for testing one method on a pre-existing web service.  That web service even comes with a test harness in the code but it's very old-school .Net and I can't fathom it - or learn for myself if I just try and pick it up.

There were several things I had to learn to do:-
1. Consume/wire up to the WCF service.
2. Read in test data from an input file.

Consuming a WCF Service

This was harder - or at least took me longer - than it should have been.  It helps if you're in a Unit Test project, rather than a class library (doh!) and in the end was relatively simple - when you know how.  I referred to the section "Accessing a service" at this page https://msdn.microsoft.com/en-us/library/bb386386.aspx to help.  It was the first I found that talked about adding a Service Reference.  Prior to that I was using the svcutil tool to create a client class, but still had some problems with that.  It looked like it was going to work but I went the "Add a Service Reference" route.

The beauty of programmatically testing a service is that in code it is just another class, and its public methods exposed are methods of that class.  So you just need to create an instance of that class and you can call its methods.  Don't forget to close  it!  I used [TestInitalize] and [TestCleanup] methods to ensure I did this properly.

A few quick tests proved I was able to all the service, receive an answer and Assert if it was right or not.  Now to automate the data input from a file.

Read in test data from an input file

Again a microsoft page was a huge help - Walkthrough: Using a configuration file to define a data source.  It struck me as odd that I found Microsoft resources more useful that StackOverflow.  I guess there's a first time for everything...

Several steps are required here, and it took some jiggery pokery to run correctly on my system but it worked.  Perhaps most imporantly, I don't (yet) understand all the decorators that were suggested.

• Update app.config with custom configuration settings.  Follow through the notes in the above link, bear in mind that at the end of that page is a complete example you can copy and paste.  In summary you need to create something like this:-

A <configuration> section containing
        <configSections> /// Standard text for a named section
        <connectionStrings>
        <named section>  /// <microsoft.visualstudio.testtools> is the standard text
              <dataSources>

I've used the full path to my input file in the connectionString attribute of the add element, with escaped backslashes \\ in the path.  I've used an excel spreadsheet as the input file because this Microsoft page gives the correct info for connecting to a spreadsheet.  I'd rather connect to a csv file, to be honest, but needs must.

• Add a TestContext into the TestClass 

The document doesn't describe what a TestContext is, or why, but you need one.  The sample text shows a private field with a public member that implements getters and setters.  You'll refer to the private field in tests so it's handy to be able to name it (with a short name).  I'd guess it's used to keep track of what row you're on in the spreadsheet.

• Decorate your Test Method

A couple of decorators are all you need - though again I'm not clear what they each do.
[DeploymentItem("TestProjectFolder\\InputFile.xlsx")]
[DataSource("UseTheNameAttributeFromTheAddElementInDataSourcesInAppConfig")]

• Import System.Data

I'd to add a reference to System.Data and pop a using statement at the top of my TestHarness.cs file.

• Write your test.

Data is imported from your spreadsheet as an object, and it seems to need you to hard code the column name.

         //Arrange
            string MPString = context.DataRow["MP"].ToString();
            if (!(String.IsNullOrEmpty(MPString)))
            {
                mp = Int32.Parse(MPString);
            }
 
            string idPrefix = context.DataRow["Prefix"].ToString();

Invoke the DataRow method of the TestContext to get the current row of your input file.  The ToString() method is available which is useful.

As you can see above, to get an int you first call the ToString method and then parse it into an int.  As I may not have any value in that column in the input spreadsheet I have to perform a check first.

You can read the expected result in from this spreadsheet too.

The Act part of the test is to call your web service, passing in whatever input parameters you require.

            //Act
            string actualResult = client.GetData(mp, idPrefix);
 
            //Assert

            Assert.AreEqual(expected, actualPrefix);

I'm using Assert.AreEqual but I find if a row fails that the only clue I get from the output is "(Data Row x)" where the first test is Row 0 (the heading row is ignored in the counting).  Perhaps a different Assert method that lets me output what the expected result or some input was would help.  For now I've added a column of numbers into my test input file as a guide.

Useful Note

I've also found that storing the test input file in my test project's folder means I can add it into the solution easily.  Then when I want to edit the input file I just double click on it in solution explorer and it launches Excel.

Summary

Add a service reference to your existing WCF service.

Import System.Data and include it in your test class file

Add a TestContext member into the test class

Use TestInitialize and TestCleanup to ensure you instantiate the service and close it properly at the end of a test.

Add a custom section into your app.config file in the test project's folder

Write your tests, with two additional decorators.  Use TestContext.DataRow to read a value from a column into a variable.

Asynchronous Programming

Old async programming with callbacks/delegates/promises

Synchronous programming blocks the main thread, which in web apps typically results in the UI blocking and being unresponsive while some backend processing occurs.

Asynchronous programming (such as C#'s Task<T> or javascript's promises) implement non-blocking asynchronous programming that frees up the UI to remain responsive by allowing the slow back end processing to occur in parallel (on another thread) and once it has completed proceeding with the program.

Historically this was achieved by the use of callbacks to signal the completion of the background operation.  If you begin to execute a long running process you invoked it with as an input parameter a callback function / pointer-to-function / delegate that would be signalled (execution would jump to) on completion of the long running process.   If program calls a long-running operation a you might pass in a delegate/the address of method b.  When the operation a completes your program resumes in method b.  If method b calls an async call to a long running process it may invoke it with a delegate of method c.  It can quickly become confusing and hard to keep track of the program execution flow.

C# 5 New model

C#5 handles much of this behind the scenes,  New asynchronous methods turn your code into a callback state machine that tracks and handles the program flow for you.

Mark your method with a new "async" modifier
Return void or Task<T> (where T is the type you would have returned normally)
Use the await operator to yield control, i.e. await <methodname>  where methodname is an asynchronous method.
Program flow resumes - in the same method -  after the awaited method has completed - but in the mean time your UI has been responsive as normal.  Thus your code looks and fields like good old synchronous code, even through it is executing asynchronously.

        public Form1()
        {
            InitializeComponent();
            ComputeStuffAsync();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
           
        }

        async void ComputeStuffAsync()
        {
            var sum = 0.0;

            await Task.Run(() =>
            {
                for (var i = 0; i < 200000000; i++)
                {
                    sum += Math.Sqrt(i);
                }
            } );
            lblSum.Text = sum.ToString();
            lblSumTxt.Text = "Once";

            await Task.Run(() =>
            {
                for (var i = 0; i < 200000000; i++)
                {
                    sum += Math.Sqrt(i);
                }
            });
            lblSum.Text = sum.ToString();
            lblSumTxt.Text = "Twice";
        }

Starting LINQ

Language Integrated Query was introduced in C# 3.0 and it allows you to query any collection - in memory, a database, etc with standard powerful logic / operators.  Historically developers had to learn multiple APIs to deal with data from different sources e.g. XML, database or in memory.  LINQ brings data access into the .Net languages (that support generics, specifically support IEnumerable<T>) and provides both intellisense and static type checking within the IDE.  These were lacking in previous data access coding APIs.   This one common way of accessing data (LINQ) is akin to the one common way of accessing external communications (WCF) which unified calls queues, web services, pipes, etc.

Out of the box LINQ provides approximately 50 standard query operators:-

• Filtering (e.g. where)
• Projection (e.g. select. Projection returns just some data attributes in an object/table, not all)
• Joining
• Partitioning (skip, take.  Useful for pagination e.g. give me results 11-20).
• Ordering (order by)
• Aggregating (group by)

Many of these are similar to SQL.

The same standard operators work everywhere.  There are additionally custom query operators / providers produced by the user community (e.g. LINQ to Amazon).

• LINQ to SQL supports SQL Server only.  LINQ to entities provides ORM features.
• LINQ to XML supports XML, with a new XML API (System.XML.Linq) that is less formal and easier to use.
• LINQ to Objects supports working with objects in memory.  This is often overlooked but is very powerful, and can replace foreach loops and selections with much more succinct code.

You can return results as collections of anonymous classes.  There are two styles/syntaxes for writing LINQ queries, Method Syntax and Query Syntax.

Method Syntax

(Very like SQL, just with the select statement at the end of the expression)
var results = from x in staff where x.Grade = "Manager"
select new {x.Name, x.PhoneNumber}

Query Syntax

(Uses a lambda expression - input parameter(s) to an anonymous method that returns a result).
var results = staff.Where(x=>x.Grade=="Manager");

LINQ Query Operators

LINQ contains some familiar and some new (but very useful) operators:

orderby

This is the same as the SQL order by clause.

            var doubleQuery = from method in typeof(double).GetMethods()
                        orderby method.Name
                        group method by method.Name into groups
                        select new { MethodName = groups.Key, NumberOfOverLoads = groups.Count() };

            foreach (var item in doubleQuery)
            {
                Console.WriteLine(item);
            }
            Console.ReadLine();

group

Same as the SQL group by clause.  (See orderby example, above).

any

Returns true if a collection has any members.
var largeList = Enumerable.Range(1,20);
var largeListEmpty = largeList.Any();
Console.WriteLine("largeList contains items? " + largeListEmpty);

contains

Returns true if a collection contains the item(s) provided in the statement
Console.WriteLine("largeList contains 7? " + largeList.Contains(7));
Console.WriteLine("largeList contains 27? " + largeList.Contains(27));

take

Takes (copies) the first n items out of the collection.
var largeList = Enumerable.Range(1,20);
var smallList = largeList.Take(5).Select(x => x * 10);

foreach (var item in smallList)
{
    Console.WriteLine(item);
}


foreach (var item in largeList)
{
    Console.WriteLine(item);
} //largeList is unchanged as the items were copied out.

Take can be a useful way of limiting your result set.

zip

Zips together two collections (presumably they need to have a matching number of items).
string[] shortMonth = { "Jan", "Feb", "Mar", "Apr", "May" };
string[] longMonth = { "January", "February", "March", "April", "May" };

var monthMapping = shortMonth.Zip(longMonth, (sMonth, lMonth) => sMonth + ": " + lMonth);

foreach (var m in monthMapping)
{
     Console.WriteLine(m);
}
Console.ReadLine();

Deferred Execution

LINQ query expressions usually do not execute until we access the result, i.e. they are lazy operators.  (Certain LINQ operators such as count are greedy and execute immediately).  Thus you can build up queries as user input changes, and only execute it once, when needed.  In the order by example, above, the LINQ query only executes when the foreach loop calls it.  It is defined first but execution is deferred until needed.  This is not unlike deploying a stored procedure in a database that only executes when called.

Summary

LINQ allows you to query any collection using one standard API
LINQ standard operators work against IEnumerable<T>
It has many useful operators
It has a powerful chaining syntax to combine operators together powerfully.

Delegates and Events

Delegates

Delegates are used to decouple the class that uses a method from the class that declares it.  A delegate wraps a method, so that you can call the method through the delegate.

public delegate int DelegateName(object inputParam)

When specifying a delegate you define the input type(s) and return type of a method that will be wrapped by the delegate.  You don't name the method, and hence the delegate can wrap any method that matches the input type(s) and return type specified in the delegate.  The delegate has no method body - that is provided/defined by the encapsulated method.

You can create a class that contains members and define a delegate.  Now, any client using your class can perform some action with the object instance of your class.  The action will depend upon the method encapsulated by the delegate - it may not be defined in your class containing the delegate.  You can pass delegates as parameters into methods - typically used to check the return type of the delegate.  You pretty much need a method in your class that takes as its parameter your delegate, so that you can use the delegate in a calling class.

The implementing method won't contain anything that indicates it is related to the delegate or your class that contains the delegate.

The calling class instantiates an object of your class.  If the implementing method is actually in a third class then your calling class needs to instantiate an object of that class too.  To instantiate the delegate, create a variable and assign to it yourclass.delegate and specify the class to be encapsulated by the delegate.


Class containing method = Document
Implementing method is "PostToBlog" in a class "BlogPoster".
Calling class:-

Document doc = new Document();  //Instantiate an object of your class
var blogPoster = new BlogPoster();  //Instantiate an object that contains the implementing method

var blogDelegate = new Document.SendDoc(blogPoster.PostToBlog);  //Instantiate the delegate, telling it to encapsulate the method PostToBlog

You're now ready to invoke the delegate.  As it is in your class you execute the method of your class that takes the delegate as its input parameter.

doc.ReportSendingDoc(blogDelegate);

This has dynamically instantiated the delegate and passed it to a method of your class, instructing it to use this delegate instance.  Your delegate will in turn call the implementing method.

You could instantiate a second delegate that encapsulates a different implementing method.  This would be invoked by calling the same method in your class and passing the second delegate.

Events

Events fire (or are raised) when something happens to trigger the event, e.g. a button click.  In C# events are implemented with delegates.  The subscribing class is encapsulated by the delegate so that the subscribing class is invoked when the event fires (delegate is called).

The convention in .Net for events means events always:-

• have a return type of void
• take two parameters - An object (the sending object) and EventArgs (or something derived from EventArgs) that could contain helper data.

Events can be used in the publish-subscribe pattern.  The publishing class (your class, above) contains a delegate so that it can raise events.  Remember the delegate won't return anything and the methods encapsulated will take two input parameters.  As well as defining the signature of methods to be encapsulated by the delegate you need to also create a member instance of the delegate that the subscriber methods will subscribe to.  This will be null unless or until someone subscribes to the delegate.  This is a useful feature as you can detect if anybody is subscribed/listening for your events and only raise them if someone is subscribed ok.

The subscribing class needs to subscribe itself to the delegate of the publishing class.  The simplest way to do this is to create a method Subscribe in your subscribing class.  This method takes as its input parameter an object of type publishing class.  In that method you add/append to the delegate your subscription, specifying the name of the class to be encapsulated by the delegate, i.e. the method to be invoked within the subscriber when the event is raised.

public void Subscribe(PublishingClass thePublisher)
{
   thePublisher.DelegateName += new PublishingClass.DelegateDefinition(SubscribingMethod);
}


The += operator adds you to the delegate's subscription list.  -= unsubscribes you.  You can have multiple subscriber to an event.  These need to be added to the list of classes that are subscribed to the delegate, rather than overwrite/replace the list.  The event keyword enforces this at compile time as it prevents you from incorrectly using just the = keyword.  The = operator would set the delegate's subscriber list (handler) to just this method, overwriting any previous subscriptions.

The solution is to use the event keyword into the publishing class at the instantiation of the delegate.

public delegate void DelegateHandler (object publisher, EventArgs otherInfo);
public event DelegateHandler delegate;

Accidentally using the wrong operator = instead of += will be detected and noted as an error at compile time.

Anonymous Methods

A delegate wraps a method so that you can call that method through the delegate.  You register a delegate and then instantiate the delegate, passing it the name of the method to wrap.  Rather than all of that - which forces you to have a separate method - you can just pass in the method itself.  You don't name the method, hence it is anonymous, but you do still use the keyword delegate.

In the events example, above, any class subscribing to an event registered itself with the event and provides the name of the method to be wrapped.  Instead of this

public void Subscribe(PublishingClass thePublisher)
{
   thePublisher.DelegateName += new PublishingClass.DelegateDefinition(SubscribingMethod);
}

you could replace the line after the += with the keyword delegate and the implementation (including signature) of SubscribingMethod thus:-

public void Subscribe(PublishingClass thePublisher)
{
   thePublisher.DelegateName += delegate(object sender, EventArgs e)
   {
              // code of SubscribingMethod.
              // resolve the naming conflict thePublisher by renaming the input param to sender
              // Put a semicolon at the end, below
   };
}

This can be a valid way to do this, provided nothing else was calling your (now anonymous) SubscibingMethod.

A more popular way of doing this is now lambda expressions.

Lambda Expressions

Lambda expressions are a more flexible and powerful syntax for anonymous methods.  The syntax is thus:
(input parameters) => {expression or block evaluating to a value}

=> is "goes to"
Input types are not provided, but type safety is assured.  There's no return keyword because it evaluates to a value.

(x,y) => { x*y };

Read as "x y goes to x times y".

To convert the above implementation of an anonymous method into a lambda expression you:-

• take out the delegate keyword and input param types
• Reformat as per coding standards for indentation
• insert the => goes to operator

public void Subscribe(PublishingClass thePublisher)
{
   thePublisher.DelegateName += 
   (sender, e) =>
   {
              // code of SubscribingMethod.
              // resolve the naming conflict thePublisher by renaming the input param to sender
              // Put a semicolon at the end, below
   };
}


You now have a lambda expression in the registration for the DelegateName event.
You read this as "Register with DelegateName the anonymous delegate represented by this lambda expression that takes two parameters.

Summary

• Defining and using delegates
• Delegates wrap/encapsulate any method that matches the signature and return type
• The delegate has no method body
• Delegates decouple the declaring class from the consuming class
• Events and how they 'fix' delegates
• Anonymous methods
• Introduction to Lambda Expressions

Interfaces

Interfaces are similar to base classes in that they create a contract that implementing classes must follow.

However, a base class is usually a "thing" (noun) e.g. Control in the previous post on abstract base classes.

An interface is usually a "capability" e.g. Enumerable, or Readable, Storable, etc.

You can implement as many interfaces as you like, to simulate multiple inheritance. (C# doesn't support multiple inheritance of classes).


Interfaces don't have access modifiers - they aren't legal.  By definition an interface has to be public.

Casting

You can't create an instance of an interface but you can create a variable of an interface that points to an instance of a class that implements the interface.  (Just like you can create a variable of an abstract base class that points to an instance of a concrete class).   You may wish to cast that variable into the type of class that it points to.  There are several ways to do this, the safest is the as keyword.

The as keyword

var myClass = new ImplementingClass();
ICapability capable = myClass;

ImplementingClass theNewClass = capable as ImplementingClass;
if (theNewClass != null)
{
    //do something class specific;
}

If the cast fails the variable will be set to null so you must always check that.

Abstract and Sealed Classes

Sealed class

A sealed class cannot be inherited from.  It is recommended for classes that won't be derived from, or only contain static methods / properties.  Typically only used if writing a library.

Abstract class

An abstract class is used to represent something (an abstraction) that should never be instantiated.  You must derive from an abstract class.  All abstract classes must be overridden.  An abstract class establishes a "contract" for all derived classes.


public abstract class Control
{
   protected int top;
   protected int left;
   public Control(int top, int left)
  {
       this.top = top;
        this.left = left;
}

public class Button : Control
{
     public string Contents;
     public class Button(int top, int left, string contents)
            : base(top, left)
     {
            Contents = contents;
     }
}

In your program you cannot do this
Control c = new Control();
because you cannot create an instance of a control as it is declared abstract.

However you can create an instance of a derived class - i.e. create the concrete class - and assign that to a variable of type Control.
Control button = new Button(2, 3, "New Button");


The benefit of this is that you can create a collection of Control objects and iterate over them because all variables are of the same type, control.   You can execute the abstract method in the base class, and each concrete class will execute that correctly because they override the abstract base method in their own way.  Polymorphism is at work again.

Polymorphism: Inheritence, Overriding and Overloading

When a class inherits/derives from a parent class it inherits all protected and public methods in the base class.

Hiding methods and Overriding

If I implement a method in the child class with the same signature as one in the base class it will hide the base class's implementation.   The compiler alerts me to this and suggests a fix of adding the new keyword.  That will work as expected in some but not all conditions.

It is perfectly legal to declare a new variable of the base class and populate it with a new child class:

Base newbie = new child();

This is because the child class has an "Is A" relationship with the base class.  A child is a base so the above works.  However if you invoke the method that has been hidden in the child class, what executes and is output is the implementation in the base class (because newbie is of type Base).  This isn't what was expected because newbie is really a child.   We want, instead of hiding the child's implementation to override the base implementation with the child implementation.

To override instead of hide a method, in the base class mark the method as virtual (which indicates we expect it to be overriden in a child class) and in the child class replace new with override in the signature of the method.

This allows the methods to implement polymorphism as the method behaves differently/correctly depending on the type of each object.
Overloading = virtual methods in a derived class.

Method Overloading

It's important to remember that the signature of a method is its name and parameter list (but not its return type).
You can overload methods - methods in a class can have the same name provided:
Different number of parameters
Different type of parameters

Overloading = same method name in one class.
You can both overload and override methods

You can also overload constructors - very handy and saves duplicating code