How to make unit testing from another project in .NET

WARNING: all this blog post is crap (error of youth ;-). Don't do this. Never. Ever. Do not test implementation details.  Follow: https://tpierrain.blogspot.com/2021/03/outside-in-diamond-tdd-1-style-made.html instead.

There is a recurrent debate around the notion of unit testing: should we only test the contracts, the visible part? or should we test the "internal affairs" of our class? In my opinion, the first proposition isn't enough. Since our teams decided to write unit tests in separate .NET assemblies (because we do not deploy test code in production, but tested code ;-), I was forced to find a trick in order to be able to query the private state of tested objects, without breaking the encapsulation. This trick is the .NET explicit interface implementation mecanism. "An interface member that is explicitly implemented cannot be accessed from a class instance, but only if the class instance is cast into the given interface." eg:

// Interface for testing purpose only, // (we always use a name like: // I<ClassToTestName>ForTesting) public interface IBoyForTesting { bool AlreadySpentAdolescentCrisis {get;} } // The class to test public class Boy : IBoyForTesting { private int age; private bool alreadySpentAdolescentCrisis; public int Age { get { return this.age; } } // Explicit interface member implementation: bool IBoyForTesting.AlreadySpentAdolescentCrisis { get { return this. alreadySpentAdolescentCrisis; } } /* ... */ } // Unit testing sample int age = 20; Boy aBoy = new Boy(age); // The following commented line would produce // compilation error because it try to access an // explicitly implemented member // bool isAdult = aBoy.AlreadySpentAdolescentCrisis; // To test this "almost private" information, you can write: Assert.IsTrue( ((IBoyForTesting)aBoy). AlreadySpentAdolescentCrisis );

With the .NET interface explicit implementation feature, you can test your classes from the outside, without too much having to break the encapsulation.

My personal motto for software development

Here are my four commandments for software development. Nothing is really new, but these are the basis criteria I try to follow each time I code a class :

1. Make it testable
2. Make it simple
3. Make it readable
4. Make it cohesive

Make it testable: because the test act like a specification and helps us to focus on design before writing our implementation code (cf Test Driven Development).

Make it simple: because complexity has several costs (difficulties to enter the code for every newcomer, painful sessions of debugage, bigger slowness for modification, ... ).

Make it readable: because source code must be human-readable (whereas binaries must be computer-executable), and because we usually do not work alone !
The choice of our method/variable names, the adoption of common naming and coding guidelines, and the quality of our source code comments (which must expose our intentions) is crucial.

Make it cohesive: because cohesion (the measure of how strongly-related and focused the responsibilities of a single class are) brings reliability, reusability, and understandability. It is essential to be capable of formalizing the responsibilities of a class in order to ensure its cohesion (I usually ask my teammates to make their best in order to write a precise and clear "summary comment" at the top of each one ot them). Highly cohesive classes are also usually easy to test (cf. Make it testable).


Like the Test-Driven Development motto (Red, Green, Refactor), I think this kind of reminder may be useful in our daily work.

Bump top rocks !!!

Here, you can discover a demo of Bump top which is a real 3D (C++/OpenGL) innovant way of representing a desktop. I really do like this kind of "new UI experience" initiative.

Long, low-energy stand up meetings tend to distract and mute the day

Martin Fowler has recently post a nice paper about patterns of daily Stand-up meetings (It's Not Just Standing Up).

I completely agree with him when he says that sharing commitment is one of the stand-up meeting success keys.

"Making daily commitments to each other as a team is the most important goal of daily stand-ups. Sharing commitment is more important than sharing progress or status. This is not to say that an observer will not have a sense of progress and status from the stand-up, but this is secondary to team members publicly committing to each other, and identifying obstacles that prevent them from meeting their commitments."

Obviously, when this commitment objective is not targeted, this may lead to situations like:

"Team members are facing and talking to the manager or meeting facilitator instead of to the team. This indicates that the daily stand-up is for the manager/facilitator when it is actually supposed to be for the team. "

To avoid the skids and to fully benefit from this kind of meeting, it is useful to keep in mind the three points that every participant must quickly address:

• What did I accomplish yesterday?
• What will I do today?
• What obstacles are impeding my progress

Juval Lowy's white papers

The well-know .NET expert Juval Lowy (author of the must-read "Programming .NET Components") has recently published some white papers such as C# coding standard, SOA design guidelines, Windows Communication Foundation (WCF) Essentials, etc.

This is available in the Resources section of the IDesign web site.

I recommand the use of the first part of the "IDesign C# Coding Standard, for development guidelines and best practices" for any new .NET project which you would begin.

On the contrary, the multi-threading guidelines part of this document is bulsh#%^$ - sorry- I mean: isn't fit to all kind of development (especially not for real-time one !!!)
=> It would have been more logical to associate it to the ASP.NET section, for instance ...

The "message bound" command pattern

How can a server dynamically handle all incoming requests without performance drawback ?

I'd been searching for a satisfactory solution to that problematic since a long time... After I recently found one, I decided to document it as a Pattern:


The "message bound" Command pattern
"A controller that dynamically handles all incoming requests without performance drawback."

Reflection is useful and more elegant than static conditional logic to decide which command a server Front Controller should run from a given message/request.

Compares to the static implementation, reflection significantly improves the productivity of the development each time we need to add a new kind of message or request type to handle.

However, this elegance has a cost named performance… The "message bound" command pattern purpose is to solve this performance drawback.

[read the pattern HERE]

Make it simple !

Contrary to appearances, the simplicity is difficult to obtain. When we develop systems, we tend to complexifier with excess. Then, the cost of the complexity of a system is directly tangible: difficulties to enter the code for every newcomer, painful sessions of debugage, bigger slowness for modification, etc.

Of course, pair programming and refactoring sessions can help us to aim towards this indispensable simplicity: It still have to be part of our objectives!

This is why I recommend you the post of Brad Abrams: "New Job Title: Senior Simplicity Engineer", and also the classical but always so relevant "The Parable of the Two Programmers".