This week was short work-wise, and went by quickly. Last week was hectic and long. Me and my colleague Truls gave a seminar on NHibernate, a little ActiveRecord and some of the new MS OR stuff. Then I spent three days with another consulting company, showing them the ins and outs of NHibernate and sprinkling just a little WCF on the last day. In so doing, I caught myself serving out some code that I have used. Normally, I don't dish out any code here, but this might be useful to some:

It's a small WCF test helper that I have used to do explorative testing of WCF and even more so for integrative smoke tests of WCF services.

There is a zip attached that contains one vs.net 2005 project with a WCF hello world and one nunit test that runs that service. That test is an integration test, it cranks up the whole WCF machinery. Most of my WCF integration tests (all, in fact) do not test any concurrency issues. They are more simple smoke tests that everything seems to work as expected. What I usually want is to test the machinery but have one instance invoked, so that I can execute some assertions on the results using that instance afterwards.

Usually, you will not implement your WCF service as a singleton (although it is one of the instancing modes), for one of several reasons - scalability for example. Using the other instancing modes means that you (by default) do not control construction of your the instance that gets to serve the requests, and thus in a test situation, we do not have a reference to the instance used by WCF. One way around this is to create a custom instance provider. The instance provider in WCF (class implementing IInstanceProvider, the default being a private class in InstanceBehavior, reflect it) is responsible for supplying new service instances. I won't talk about it here, suffice it to say that my SingletonInstanceProvider simply returns one (settable) instance each time, thus making the service a singleton. It is a service behavior that we add to the servicehost description.

Why do this? Simply so that I can implement my service using an instancing mode that I want, but still run simple smoke tests on it. It is one solution, there are doubtless many others, if you have a better one, please give me a shout.

So, the testhelper or testharness that is enclosed actually does a couple of things. I won't talk about them in detail, this is roughly it:

• Provide a simple way to create and start a service host and get a client to run tests against it.
• Provide a way for tests to share services, so that the WCF machinery does not need to be restarted.
• Get the services set up using the SingletonInstanceProvider easily
• Allow test to access host before it is started to modify/further configure
  ( this is why you see castle in there, the client (a dynamic proxy wrapper) is actually a proxy that opens the service late/JIT )

You use it like so:

IMessageOfTheDay client1 = GetClient

   .For<IMessageOfTheDay>()

   .Using(new NetTcpBinding())

   .Running(serviceInstance);

This sets up a service host for the IMessageOfTheDay service contract, using the netTcpBinding (optional, default is named pipes since it is the fastest) and running the instance supplied. See the demotest.

Comments welcome. Btw, this uses my singleton implementation, I'll make a note of that tomorrow, but it's simple.

Questions: Has anyone seen another wcf test harness like this? I usually do all my network integration testing using some thread harness with synchronization between, and did my WCF testing in a similar (not the same) way. This harness simplified things quite a bit.

BTW: Most of the code is in one file; TestHelper.cs. It's a bit unwieldly, sorry, but easier to copy - you still need the singleton.cs though. I may update later if I get time.

Again, the download is here.

I am here in Cambridge, at the SPA conference, and held a workshop on testability and encapsulation. I promised to publish my sources, so here they are! I will post presentation in the near future.

Most of the articles can be found via acm (portal.acm.org) or ieee, but I always search via google which usually leads to acm.

Abstraction, information hiding and encapsulation

Most of the good stuff here is from different OOD books. Here are some old articles I found interesting, (tiny archaeological warning), worth skimming:

    "Data abstraction and hierarchy"
        Barbara Liskov
        OOPSLA 1987
    "Encapsulation and inheritance in OO programming languages"
        Alan Snyder
        OOPSLA 1986
    "Encapsulation constructs in systems programming languages"
        W. F. Appelbe, A. P. Ravn
        ACM Transactions on

        Programming Languages and Systems (TOPLAS)
        April 1984

Parnas on information hiding is classic but the examples dated.

    "On the criteria to be used in decomposing systems into modules"
        D L Parnas
        Communications of the ACM, December 1972

Abstraction is not mechanics of coupling, but is about semantics and meaning - designing is creating models that communicate:

    Good vs. Evil: Abstraction
    Manuel Klimek, article on blog
        http://klimek.box4.net/blog/2007/03/18/good-vs-evil-abstraction/

Testability

If you read just one article on testability, Binders old from 12 years ago is the the best I've read. You will have to "translate" concepts to todays terms, and it pretty condensed (but it is at the same time not "being difficult"), read it twice.

    "Design for testability in object-oriented systems"
        Robert V. Binder
        September 1994 Communications of the ACM

The first article I've read that actually talks about testability of software with respect to test creation in a pragmatic way, is Freedman. It is still interesting, although not as current. It's non OO and a bit silly on the math side, especially for a practicioner, but I just skim that...

    Testability of Software components
        IEEE Trans. Software Eng. 17(6): 553-564 (1991)   
        Roy S Freedman

Not so long ago I found an excellent recent summary of testability work, that I could have made good use of earlier. (Note the weird publishing spot.)

    "Predicting Class Testability using Object-Oriented Metrics"
        Magiel Bruntink, Arie van Deursen
        September 2004
        Proceedings of the Source Code Analysis and Manipulation, Fourth IEEE
        International Workshop on (SCAM'04) - Volume 00 SCAM '04

Magiel Bruntinks "Testability of Object Oriented Systems: a Metrics based approach" (dissertation, 2003) is pretty nice as well.

We talked about two basic models of testability, which were kind-of based on Binders categories of fault and conformance directed testing. A model of testability that focuses on fault directed testing is that of Jeffrey Voas. He has published alot, I found this article to be the most accessible:

"Software Testability: The New Verification"
    IEEE Software may 1995
    Jeffrey M. Voas, Keith W. Miller

There are a couple of others worth checking out, this one is ok:

"Factors that affect software testability"
     Voas Jeffrey M.
    October 1991          
    Technical Report
    Publisher: NASA Langley Technical Report Server (available via acm)

Stefan Jungmayr has published alot an+d has focused on dependencies and metrics, this short article sums up alot of his work. Both this and more can be found on www.testability.de/E_index.html:

    "Testability and unit testing"
        Stefan Jungmayr

His dissertation is lengthy, there is some useful stuff there. His clear definitions of dependencies are a good contribution.

Books

If you want a good and accessible text that does cover a lot of the issues we talked about, I really have found good use for Feathers "WELC" book. I recommend it to anyone learning behavior driven or test first design as well.

    "Working effectively with legacy code"
        Prentice Hall, 2004
        Michael Feathers

Chapters addressing test construction factors: Chapter nine and ten talks about controllability and a little about observability. Other chapters talk about design and abstraction, notably chapter 17. Great book on the subject of testing object oriented code, one of the best IMHO.

There's also Binders enormous book, which is not mentioned that often, so I'll mention it. The parts I've read are excellent, but it's quite enormous. He should have split it into several.

    "Testing Object-Oriented Systems: Models, Patterns, and Tools"
        Addison-Wesley 1999
        Robert V Binder

Testing general

I brought up some stuff (the testing periods, etc) from an old article that is really nice, and highly recommended, well worth a read. Short easy read that has many insights, although it is a bit historical.

    The growth of software testing
        D. Gelperin, B. Hetzel
        June 1988, Communications of the ACM,  Volume 31 Issue 6

This is an old classic and still very amusing read, could use another font:
    "In defense of program testing or Correctness proofs considered harmful"
        Andrew S Tannenbaum et al
        ACM SIGPLAN Notices Volume 11 ,  Issue 5  (May 1976)

OO

I mentioned the study on core OO concepts:

    "The quarks of object-oriented development"
        Deborah J. Armstrong        
        Communications of the ACM  archive, February 2006

TOOP - Testable object oriented programming

There has actually been some work on what testable object oriented programming might mean. What I've read has not been terribly interesting, but here is one I read anyway:

    "On testable object-oriented programming"
        Y Wang, et al
        ACM SIGSOFT Software Engineering Notes, July 1997