Software Development Accelerated Essentials: What You Didn't Know, You Needed to Know

Developmental: Build The Company

Environments

To the entry level, developer, or IT person:

In ten words or less; you have multiple environments.  These are either physical or virtual servers or both, which mimic your production environment. 

Production is your live environment where users do their business.  It must be kept pristine and free of defects at all times.  It must be reliable and readily available. 

A production release is where your software is tested, then QA (Quality Assurance) tested, then UAT (User Acceptance Test) tested and then approved for production deployment.

Development:

Test all your code here.

Don’t worry if you’ve broken anything.

QA (Quality Assurance)

Modules and applications are moved and tested by the QA staff and they must signoff.

UAT (User Acceptance Test)

This is tested by the actual production user of your application.  If you work in the financial industry, this could be a stock market trader.

Users provide the final signoff.

Production

This is the live environment used by your clients.

This environment is supported by a production support team and as a developer, or QA person, you will not have access to it. 

Chinese wall:  A terminology for role separations.  It provides the safeguards for rogue persons to either willingly or unknowingly adversely affect your production environment.  A developer writes the code.  A QA person and UAT person validates your code and the production support staff support it.  You’ll more about this in subsequent chapters.

I will review all aspects of the release process but first we begin with developer fundamentals.  But there will also be chapters on deployment specific protocols and principles.

If you’re a QA or BA person, you can skip to those chapters but it’s advisable to have a complete understanding of the software development process.

Most importantly and just to reiterate, the examples in this book are written in C#, however JAVA, C++ are similar in syntax and these are principles that span all type-safe languages.  A JAVA or C++ developer can easily follow the sample code. 

For the developer only:  this book assumes you are proficient with your programming language.  This is not a programming language primer.

O.O.P: Object Oriented Programming

According to Wikipedia: https://en.wikipedia.org/wiki/Object-oriented_programming (Kendler and Lewis) Excerpt below:

____________________________________________________

Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of this or self).  In OOP, computer programs are designed by making them out of objects that interact with one another. There is significant diversity of OOP languages, but the most popular ones are class-based, meaning that objects are instances of classes, which typically also determine their type.

Many of the most widely used programming languages (such as C++, Object Pascal, Java, Python etc.) are multi-paradigm programming languages that support object-oriented programming to a greater or lesser degree, typically in combination with imperative, procedural programming. Significant object-oriented languages include Java, C++, C#, Python, PHP, Ruby, Perl, Object Pascal, Objective-C, Dart, Swift, Scala, Common Lisp, and Smalltalk.

____________________________________________________

The Three Tenets of OOP

The Code Project definition boils down to the below three tenets:

Inheritance

Allows for code reusability.

Create a base class.

Inherit from a base class and extend your child component without altering the base or super class.  Supports the Open/Close Principle (I’ll describe in more detail later in the book).

Using Virtual or Abstract methods, allows you to override or provide your own implementation.

Encapsulation

Keep your logic self-contained within an object.

Hide your code.

Organize your code into small cohesive units.

Polymorphism

Various objects can share the same interfaces.

Objects can share an interface with their own implementation of their personalize logic.

The Strategy Pattern discussed in later chapters, provides more details.

The Object-Oriented programming is something the reader should already be familiar with or at least have a basic understanding.

The S.O.L.I.D Principle

This single acronym is the single most important principle you must adopt, if you wish to be a successful developer.  It builds off OOP described earlier.

S — Single Responsibility Principle

O — Open/Close Principle

L — Liskov substitution Principle

I — Interface Segregation Principle

D — Dependency Injection Principle

I’ll first cover the SOLID paradigm with a brief overview and rudimentary examples.  Everything will start to make sense as we begin to code.  All we’re doing in this chapter is setting up our foundation.

The SOLID paradigm was first introduced by Robert Martin.  Please be advise that this book is not just another book about the SOLID paradigm but it’s a required knowledgeset that along with Best Practices and design patterns will help you to produce robust quality code.

S — Single Responsibility Principle

According to Wikipedia https://en.wikipedia.org/wiki/Single_responsibility_principle (R. C. Martin)     Excerpt below:

____________________________________________________

In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

____________________________________________________

Simple Translation: An object should only have one reason to change.

When you have an object doing too much, it becomes brittle and difficult to maintain. 

Here’s an example, you have a Winforms application for an employee database maintenance screen.  All the code is in the GUI, including calls to the database and all the business logic.  Anytime you need to change something on the database, or the business requirement changes, you need to update and then redeploy your GUI front-ends or back-ends.  If you assume every other JIRA monkey codes the way you do, deployments become a nightmare because it’s not just your app but other apps as well that require maintenance and regression testing.

Single responsibility and separation of concern (which will discuss in detail later) should consist only of widgets, like buttons, drop-downs, colors, etc... 

If your GUI code contains the database access logic, then if backend database changes, let’s say from Oracle to MS SQL Server, every single GUI and/or every application you have that accesses the database directly, will have to be upgraded.  When the database logic changes, so must your GUI and its redeployment.

Had you added a data access layer, and had your GUIs accessed your access layer via an interface, then none of the front-ends using this access layer would need to be redeployed, nor recompiled.  You merely deploy the access layer as a DLL.

The data access object has only one responsibility and that is to retrieve and process data. This protocol will morph into the Repository Pattern, which will cover later.

Let’s not confuse the Single Responsibility with Separation of Concerns; in this case however, the data access object complies with both principles.  It’s responsible for processing data only and is extracted into its own DLL (Dynamic Link Library, you should be familiar with this term) and is separated from the GUI front-end.

Separating your business layer from the GUI, makes it testable because you can write automated test cases to validate your business logic.  You’ll be seeing examples soon.

O - Open/Close Principle

https://en.wikipedia.org/wiki/Open/closed_principle (Meyer) Excerpt below:

____________________________________________________

In object-oriented programming, the open/closed principle states software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification; that is, such an entity can allow its behaviour to be extended without modifying its source code.

The name open/closed principle has been used in two ways. Both ways use generalizations (for instance, inheritance or delegate functions) to resolve the apparent dilemma, but the goals, techniques, and results are different.

Open-closed principle is one of the five SOLID principles of object-oriented design.

____________________________________________________

Simple Translation: Try not to alter existing code as much as possible.  (We’ll discuss two patterns, the Template and Strategy patterns, which lend themselves well to this philosophy.)

How is the even possible?  What do you mean, open for extension but closed for modification?

Here’s Why, the Template and the Strategy patterns exists.  I’ll be going through examples later but let me just for now, give you a quick one:

Let’s take the Template pattern for example; I create a base or super class (JAVA term).  I make the methods virtual where I provide the logic and I include abstract methods where you supply the logic.  Any client can then inherit from the base class and merely override a method’s implementation.

Keep in mind, every application should have its own suite of automated test cases and you should realize that you’re not changing the base class code base, so you can’t possibly break it.  You can break your inherited child of that base class but you won’t affect the base class itself.  But if you change the base class, you then have the possibility of breaking all clients which inherit from it.  That is why all applications must have automated test case to prevent feature bug injection.

There are developers of the mindset which favor composition over inheritance, when you inherit from an object; you’re coupled to it, whereas in composition, you’re injecting an interface.  With this, if you break the base class, since the client is not tightly coupled via inheritance; you can merely drop a corrected base class without the need for compilation.  We’ll review this practice later on, I promise, there’s lots more to cover.  

Remember the key word is favor; it doesn’t mean you should never use inheritance; it just means composition is preferable as it’s less coupled and more maintainable, which you’ll see when I introduce the Strategy Pattern.

Here are excerpts from Artima.com below:

____________________________________________________

One of the fundamental activities of any software system design is establishing relationships between classes.  Two fundamental ways to relate classes are inheritance and composition.  Although the compiler and Java virtual machine (JVM) will do a lot of work for you when you use inheritance, you can also get at the functionality of inheritance when you use composition. This article will compare these two approaches to relating classes and will provide guidelines on their use. 

and ...

In an inheritance relationship, superclasses are often said to be fragile, because one little change to a superclass can ripple out and require changes in many other places in the application's code. 

____________________________________________________

I will give examples in later chapters on how to implement each principle.  

The Template Pattern lends itself better to inheritance whereas the Strategy Pattern, which I’ll cover later, lends itself well to composition.  So, once I review the Strategy Pattern, you’ll see the difference between inheritance and composition.

So now you know Why you need the Template Pattern and you just learn briefly, the How to implement it and you’re practicing the SOLID paradigm.  So far, you’re in good shape.

I’m only skimming the surface.  We’ll get into more detail soon, I promise. 

L- Liskov substitution Principle

According to Wikipedia: https://en.wikipedia.org/wiki/Liskov_substitution_principle  (Liskov) Excerpt below:

____________________________________________________

Liskov's notion of a behavioral subtype defines a notion of substitutability for mutable objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness).

___________________________________________________

Simple Translation:  You should be able to substitute an inherited class in place of its base class.  An inherited class must not change the initial implementation of the base class.

Ask yourself this question, using the above description, can you inherit from a Square object and use it to create a Rectangle? 

The answer is clearly No! because in a square all sides must be equal whereas for rectangles the length and width can be different.  So now, if you inherit from a square to create a rectangle, you’re breaking the Liskov subsititution principle because you’re forcing an object to do something it was not intended to do and you’re violating its initial restriction.

I’ve given you a simple example by choosing a square and rectangle but in the real world you’ll need to ask yourself this question when using inheritance.  Let’s take a real-world example. 

Options; in the financial industry, an option allows the purchaser to either buy (call) or sell (put) an instrument such as a stock.  There’s a difference between a Vanilla option versus an Exotic.  You wouldn’t create an Exotic option from a vanilla one because the differences vary greatly. 

Vanilla options all have standard features with possible subtle differences in expirations and maturity dates, whereby Exotic options are radically different, examples are Chooser Options, Barrier Options, Asian Options...etc.  You would break the implementation meant for a Vanilla to create an Exotic option and you probably could do it but the code would be a mess and difficult to maintain.  You’d be adding features to a child of a Vanilla option which wasn’t meant to act that way. 

Be very careful breaking the Liskov’s principle because this a principle which should always be considered in the forefront of your thoughts.   There is nothing stopping you from violating it and causing adverse effects. And you might not learn about an issue, until it’s too late and you’ll learn the hard way, when you have to rewrite your code or rollback your changes and damage your reputation as competent developer.

If the option example is difficult to understand then just go with the Square/Rectangle example.  I wanted to provide you a real-world example for those familiar with Stock Market terms.

I - Interface Segregation Principle

According to Wikipedia: https://en.wikipedia.org/wiki/Interface_segregation_principle (R. Martin)  Excerpt below:

_____________________________________________________________________________________

ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.  In a nutshell, no client should be forced to depend on methods it does not use. 

_____________________________________________________________________________________

Simple Translation: You have an interface with 10 methods and all you need is two, so make another interface with just those two methods.

On the next page are two interfaces, let’s say I started with an interface IExtractionService, and there are several methods to choose from but some clients only have the need to either Validate or Execute an item.  If they inherit from the IExtractionService then they’ll have empty methods with no implementation.  In this case, merely create a client specific interface.  There are also times you may wish to isolate certain features, isolate them by providing an interface without those items.

Be aware that although there are no multiple inheritances for objects in C#, .Net does allow for multiple inheritances of interfaces.  So, you can combine interfaces to be more user specific.

Don’t worry too much if this doesn’t make sense to you, that will clear up when we get to examples.

D - Dependency Injection Principle

According to Wikipedia: https://en.wikipedia.org/wiki/Dependency_injection (Shore) Excerpt below:

_____________________________________________________________________________________

Dependency injection is a software design pattern that allows a choice of component to be made at run time rather than compile time.  This can be used, for example, as a simple way to load plugins dynamically or to choose mock objects in test environments vs. real objects in production environments.

_____________________________________________________________________________________

Simple Translation: You need the ability to inject objects that will do work for you and pass them into your client's constructor.

This too will make sense and is included as part of first test case. 

Two more Tenets:

Besides the five tenants of the SOLID paradigm, here are to more you should add to the S and the D and they are:

S – Separation of concerns

According to Wikipedia: https://en.wikipedia.org/wiki/Separation_of_concerns (laplante and Mitchell)

Excerpt below:

_____________________________________________________________________________________

In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern.

A concern is a set of information that affects the code of a computer program.  A concern can be as general as the details of the hardware the code is being optimized for, or as specific as the name of a class to instantiate.  A program that embodies SoC well is called a modular program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface.  Encapsulation is a means of information hiding. Layered designs in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer).

_____________________________________________________________________________________

As all Developers know (or should already know), your application should be separated into layers.  Just as the internet is separated into layers whereby each layer is responsible for a single concern, so should your application be structured in this manner.

From the internet protocols, we have HTTP (Hyper Text Transfer Protocol); we know this allows for the browser layer of the Internet protocols.

Layers such as FTP, is used for file transferring files

SMTP is the Simple Mail Transfer Protocol.

These are just a few of the protocols but I wanted to use them as an example whereby each protocol has only one concern whether it be communicating with a browser, sending or receiving files, or sending email.  There are many others.

From an application standpoint, you have three layers:

Presentation Layer

Business Layer

Data Access Layer

Each of these three layers has only one concern.  They should not have any knowledge for the other layers.

The Presentation Layer could be an ASP page, a Winform, or a WPF frontend.  Their only concern is presenting the data.  It doesn’t matter where the data comes from nor the business logic involved.

The Business Layer is just that, its only concern is the business requirement.

The Data Access Layer’s only concern is getting the data.  Whether that is from an Oracle, Sybase, MS SQL server database, doesn’t matter, it will fetch the data.  I’ll briefly mention the Hollywood Principle, Don’t call us we’ll call you.  Which means, Just tell me what you want and I’ll get it for you?

All these layers must be abstracted from one another; and how do we abstract things?  By Interfaces, of course.  We’ll delve more into that later.

I’ve only skimmed the surface; for more in-depth knowledge of the SOLID paradigm and other object-oriented principles, I highly recommend Robert Martin’s book, Agile Principles, Patterns, and Practices in C# distributed by Prentice Hall.

D – Law of Demeter

According to Wikipedia:  https://en.wikipedia.org/wiki/Law_of_Demeter (Holland)  Excerpt below:

_____________________________________________________________________________________

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs.  In its general form, the LoD is a specific case of loose coupling. The guideline was proposed by Ian Holland at Northeastern University towards the end of 1987, and can be succinctly summarized in each of the following ways:

• Each unit should have only limited knowledge about other units: only units closely related to the current unit. 

• Each unit should only talk to its friends; don't talk to strangers.

• Only talk to your immediate friends.

_____________________________________________________________________________________

Simple Translation:  The less your object knows about a class, the better.  Only work with objects which your object already owns or were passed to it via the constructor or property.

Let’s think about this one for a moment; If, in my constructor, or within a method, I create a new object that wasn’t passed to me, how can I test it?

Sample code:

Don’t use the new keyword to instantiate objects inside a constructor or method, instead pass the object via the constructor and keep a reference to it.

In the wrong example, what happens if the MessagService is replaced?  Had I passed an IMessageService into the constructor (correct way) or as a parameter (had this been a method invocation), I could pass any implementation of that service.  I could also create a mock for it, in my unit tests.  You’ll learn more about mocks in later chapters.

The law of Demeter isn’t just for testing; it’s to guide you to make your classes loosely coupled.

Always code to an abstraction, never to an implementation.  Never hardcode classes, always code to an interface.  You’ll learn more on how to do this when we cover refactoring.

I’ve given you a brief overview of the SOLID paradigm, from this point forward we’ll dive into code.

We’ll first start with the business requirements, also referred to as the functional specs. 

We sat with the user and they told us what they wanted. 

Functional Specs

Get latest Market data (Bid and Ask Spread).

Allow different data sources, Reuters, Bloomberg, Market pro.

Allow for different exchanges:

Domestic

NYSE, Chicago, and Pennsylvania

International

London Stock Exchange, Paris Stock Exchange, Tokyo

Restrict securities:

By region, security type or company.

Allow the execution on an exchange with the best price.

Allow the user to select exchanges.

Favor one over another.

Best price

Execute a trade when a specific price point is met.

Allow it to execute in batches.

Wow, there’s a lot of stuff in there?  Where do I begin?

You can't eat a meal all at once, you need to take bite size chunks and it’s the same with software development. You can’t code the entire application at once, so code one method at a time.  This will also allow for a bottom-up approach.

OpenClose Principle

There are two design patterns in particular which lend themselves well to the OpenClose Principle. One is a template pattern and the other is a strategy pattern. Many of you may already be working with a template pattern and not even know it.  If you inherit from a base class with virtual methods, that's a template pattern.

For the Open/Close principle, we're using a banking example. In our scenario, all banks use the same logic for deposits, however, withdrawals are bank specific. We want to create an object that is open for extension but close for modification. By creating a base class with virtual methods, there's no need to change it, we merely override the method that is different for a bank, which in our case, are the withdrawals. If you don't override the withdrawal method, you're given a default implementation, which is to reduce the available balance by the withdrawal amount.

Open/Close Solution Structure:

Template Pattern

Here's the base class or the template class which will be inheriting from:

Commbank allows for an overdraft limit of 1000. (Not really.  This is fictitious)

We inherit from Banking class and merely override the Withdrawal method as indicated.

Deposit logic is handled by the base class, so we don’t need to override that one. 

We have extended the functionality without modifying the base class.

Now, let's discuss how we would do this using the Strategy pattern.

Strategy Pattern

Let's look at what I call an ugly if

Every time a new bank comes in, I'll need to add it to this UglyProcess method. Not only that, but I also have to create another bank specific withdrawal method.

Here's one for FedFedility (Again, all this is fictitious) 

Now, the ugly if gets even uglier:

DailyProcess:

This means another build and another release which, could result in a regression failure by you inadvertently adding a bug to existing code.  The less you touch your code and the more automated test you have, the better.

This violates the Open/Close principle whose purpose is to avoid introducing bugs, to an existing codebase and which facilitates code maintenance.

Now let's look at an open close way using a strategy:

Very little code, right? That's because all bank specific code is now in its own strategy.

In this example, which is common with the strategy pattern, we'll also be soliciting the assistance of a Factory.

We'll create an IBankingProcess Interface which all banks must inherit from.

You'll notice the Interface has four methods; Withdrawal, Balance, Deposit and Process.

Here’s the entire solution structure:

FedFidelity is different than Commercial Bank, in that is has a reserved amount of $200, meaning the customer must maintain a $200 balance all times.

Now, each of these strategies can inherit from Banking and IBankingProcess and override the withdrawal, that’s an example of the Template Pattern. But for this Strategy Pattern example, all bank related code is self contained in its own DLL. 

Here’s an example of favoring composition over inheritance.  I compose a DLL for each banking strategy and I have no dependency on a Banking class. 

Quite often you’ll find yourself using more that one Design Pattern.  We’re going to incorporate a Factory Pattern that our client calls to get the correct Strategy for a specific bank.

I have a dictionary with all the IBankingProcess banks and a default also known as a null object (This will be discussed in shortly).

The GoodProcess no longer needs to be updated and it is therefore closed for modification.

The Factory is the only one that will require updates but we create a brand-new strategy and merely load it into a dictionary.

We can go one step further and use reflection to load all IBankingProcess objects into a specific directory and then use Reflection at run time to load all bank strategies at run time. And this too, will be totally Open/Close, because you'll never need to update it just to add another bank because so long as your bank is inheriting from IBankProcess, it will automatically get loaded at run time by reflection. This means deployment is facilitated merely by dropping a dll in a pre-defined directory.  Microsoft Prism 5.0 IOC has a facility of a DirectoryCatalog for loading DLLs based on a directory structure at runtime

For more information, download the MS Prism PDF from here:

https://www.microsoft.com/en-us/download/details.aspx?id=42572

GoodProcess asks the BankingFactory for a particular bank which the Factory fetches and returns. It then merely calls the banks Process method and it passes it a bankTransaction for processing. What happens when a bank is passed with no banking strategy?

If the factory doesn't find an associated bank strategy, it merely passes back a null object or a default logic, if you will.

––––––––

A Null Object provides default implementation when none is available.  The code didn’t need to check if the Factory returned null.  So, it didn’t need to code:

Because the Factory returns a default implementation, it’s therefore, Open/Close, as no modification to this code is necessary.

Liskov substitution Principle

Now, let's look at a Liskov substitution example:

Let's look at a square; in a way a square is very much like a rectangle, in that they both have a length and width; however, a square requires all sides to be equal.

So why not merely inherit from a rectangle and impose this restriction, right? 

Okay, so I Inherit from Rectangle and I pass the length twice as length and width into rectangle.

It just so happens that there's a method for calculating a standard lot which requires the length to be longer than width. We didn't know of this restriction and tried to violate the Liskov principle by attempting to make a base class do what it was never intended to do.  But we knew that a Square must have the same sides which is not a restriction for a Rectangle, so we never should have inherited from it.

For a rectangle, it's easy to see that a square is not a rectangle because the sides must be the same length.

But what about when it's not so obvious, such as the case with bonds.  Not all bonds share the same characteristics.  A bond and zero-coupon bonds are slightly different.

Bond Maturity

Face Value

Coupon

A zero-coupon is a type of bond that makes no coupon payments but instead is issued at a considerable discount to par value.  A zero-coupon bond doesn’t have coupons while a normal bond does and is required.

For example, let's say a zero-coupon bond with a $1,000 par value and 10 years to maturity is trading at $600; you'd be paying $600 today for a bond that will be worth $1,000 in 10 years.

However, if we remove or override the Coupon property from the base class, then we can't use it for normal bonds because it will no longer have that restriction.  You might create base classes with share commonality to inherit from but don’t violate a base class’ restriction simple because it would be quick to inherit from. 

Unit Tests

Unit test are broken down into three parts:

Setup

Run the Test

Teardown

Keep in mind the triple A of unit tests: (see the Art of Unit test by Roy Osherove)

https://www.goodreads.com/book/show/6487349-the-art-of-unit-testing

Arrange

Setup your tests. 

Act

Invoke your method under test.

Assert

Use the frameworks, Assert command to validate your test.

The concepts of Stubbing and Mocking will be covered in a later chapter but I’ll provide a brief overview.

We’ll start by doing a virtual peer programming.  Peer programming is an Agile concept whereby two software developers code side by side.  It produces better quality code. 

I can’t be there physically with you, so I’ll provide instructions as bullet items and then we’ll follow along with screen shots.

Writing Unit test Cases:

Start by creating a test fixture project.

If you choose MS Test, you create a Unit Test Project (see screen shot below).

If you choose NUnit, or anything other than MS Test, merely create a class library and add the testing framework and Moq or RhinoMock references.

Next create an empty Interface.

Followed by an empty class.

Add references for Nunit, and RhinoMock or Moq (whichever mocking framework you choose.  There are many to choose from.)

Note:  MS Test does not require adding references to it, as you’ll create an MS Test project which will include its references.

XUnit is another testing framework you may wish to consider using.

You don't have to necessarily pre-create the interface, start immediately from the test case.  Resharper will create the interface for you by hitting alt-enter.  Have the empty class inherit from Interface.  (I have a section on Resharper and I will provide a link to the mapping template)

Let ReSharper create the methods for you.

Create your assertions.

Create test cases to initially fail:

You should invalidate your test, as all tests should fail because of lack of implementation.

They should only succeed when the implementation is added.

Please Note:  The default Resharper option for creating methods is to throw NotImplementationException.  You should keep this as your default.  Also, if you’re not using Resharper, Visual Studio 2010 and up provide similar features but I highly recommend using Resharper.  If you’re company won’t foot the bill, then get it for yourself, it’s well worth the money.

I know this sound like a bit much but as I mentioned, here are easy to follow screen shots.  But if you don’t know how to use Visual Studio and/or are unfamiliar with adding references then put down this book and go get training. 

Using MSTest

Using NUnit

A Unit test:

Must not make any references to any environments.

This is a unit test, not an integration test, so it shouldn’t reference any environments.

Must be self-contained.

A setup and tear down for each method.

Must not reference any other test.

Must test only one method.

Must test only one feature.

Must test for success.

Must test for failure.

Must be reliable.

Must run quickly.

Object under test

Mocking and Stubbing

Mocking is a process by which you create a fake object, you tell it to expect a call and then tell it what to return.  I have a section on using RhinoMocks and Moq.  Please note:  RhinoMocks hasn’t been upgraded in quite some time, so use it with caution or use something else.  I’ve used it for many years and I’m comfortable describing my real case scenarios with it.  My goal is merely to provide you the concept of mocks.

Stubbing is a process by which you also create a fake class and you stubbed out responses.  So, you inherit from an interface and for testing purposes only, you provide a response.  I’ll cover this in further detail later.

In our examples we’ll either be using RhinoMocks or Moq, which have their own chapters.

I’ll only cover the basic but I’ll provide links on where to learn more about them.