Creating your own primitive type

It’s a very rare requirement, but sometimes in .NET you have to create your own primitive and make it behave as close as possible to a native CTS (common type system) type. “That shouldn’t be hard” would be your first thought, until you start considering all the scenarios in which it could be used.

Unit Testing – Setup pattern (Moq)

Frank Code

In my previous post I mentioned that large unit test setups can be difficult to maintain / understand. This problem can be reduced by following a test pattern. I want to share with you a pattern I use, and I think works really well. In this post I will be using C#, Moq libary and Visual Studio test tools.

To start here are some things I believe make a good suite of unit tests:

• Easy to identify data dependencies of tests.
• Mocking is not repeated every test.
• Test are clear and easy to understand / maintain.
• New tests can be added with relative ease.

In order to explain this testing pattern I have forked my buddies TodoMVC app, and introduced a service layer, repository pattern and test project. You can see my source code with an example test class on github.

The TodoModule (service layer) has a number of public methods; Get…

View original post 315 more words

Object Oriented, Test Driven Design in C# and Java: A Practical Example Part #1

Download the code in C#

For a brief overview, please refer to this post.

At this point, many tutorials start by launching into a “Hello, World” style tutorial, with very little practical basis.

This isn’t the most exciting concept, so let’s try a more practical example. Instead of churning out boring pleasantries, our application is going to do something a bit more interesting…build robots.

Specifically, our application is going to build awesome robots with big guns.

Ok, let’s get started with a narrative description of what we’re going to do.

“Mechs with Big Guns” is a factory that produces large, robotic vehicles designed to shoot other large, robotic vehicles. Robots are composed of several robotic parts, delivered by suppliers. Parts are loaded into a delivery bay, and are transported by worker drones to various rooms; functional parts such as arms, legs, etc., are dispatched to an assembly room. Guns…

View original post 876 more words

SOLID principle

Chanmingman's Blog

There is a lot of debate on SOLID principle.

The video Applying SOLID Principles in .NET   (http://channel9.msdn.com/events/TechEd/Europe/2014/DEV-B210) is worth to watch.

I like the last slide Consideration

As he mentioned.

1. Someone just over engineering using the term SOLID

2. How readable for your Dependency Injection if you have large set of object.

3. When talking about maintainable, before SOLID is 50 lines of code, after SOLID is 230 lines of code previewing the same functionality. So you think 50 lines of code is easier to maintain or 230?

View original post

Erik Meijer: AGILE must be destroyed, once and for all

Enough of the stand-up meetings please, just WRITE SOME CODE

Comment A couple of months back, Dutch computer scientist Erik Meijer gave an outspoken and distinctly anti-Agile talk at the Reaktor Dev Day in Finland.

“Agile is a cancer that we have to eliminate from the industry,” said Meijer; harsh words for a methodology that started in the nineties as a lightweight alternative to bureaucratic and inflexible approaches to software development.

The Agile Manifesto is a statement from a number of development gurus espousing four principles:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

An introduction to Single Responsibility principle (SRP)

SOLID design principles in .NET: the Open-Closed Principle

Exercises in .NET with Andras Nemes

Introduction

In the previous post we talked about the letter ‘S’ in SOLID, i.e. the Single Responsibility Principle. Now it’s time to move to the letter ‘O’ which stands for the Open-Closed Principle (OCP). OCP states that classes should be open for extension and closed for modification. You should be able to add new features and extend a class without changing its internal behaviour. You can always add new behaviour to a class in the future. At the same time you should not have to recompile your application just to make room for new things. The main goal of the principle is to avoid breaking changes in an existing class as it can introduce bugs and errors in other parts of your application.

How is this even possible? The key to success is identifying the areas in your domain that are likely to change and programming to abstractions. Separate out…

View original post 1,201 more words

Extending mocking with Moq

Coding Journeyman

In the last part of my Dependency Injection article I introduced the term of “mocking”. This kind of test double can be really powerful. Yet in my example I had to create 2 new classes (my mocks) to be able to test my functionality in order to reduced coupling. Here is the code used by the tests:

class MockNotifier : INotifier
{public MockNotifier(){
        NotifyHasBeenCalled =false;}
 
    publicbool NotifyHasBeenCalled {get;privateset;}
 
    publicvoid Notify(User user){
        NotifyHasBeenCalled =true;}}
 
class MockRepository : IUserRepository
{publicbool HasValidatedNotification {get;set;}
 
    public User GetById(int userId){returnnew User { HasActivatedNotification = HasValidatedNotification };}}
 
[TestClass]publicclass NotificationServiceTest
{private NotificationService _notificationService;private MockNotifier _mockNotifier;private MockRepository _mockRepository

View original post 659 more words