# Recursive Descent Parser for arithmetic expressions with real numbers

In previous post we were building Recursive Descent Parser for Boolean expressions and in the post before that we were parsing simple arithmetic expressions (with only addition and subtraction).

In this third, final post we will build more real world example – we will parse arithmetic expressions that include (besides addition and subtraction) multiplication and division. Note here that we also have to respect the priority of operations (multiplication and division are done before addition and subtraction) so our parser has to be “smart” enough to handle that. And just to make it more fun, this time we will also support real numbers instead of just boring integers.

#### Grammar

As usual, lets start with the grammar – i cannot stress how important this step is for the whole process:

```Expression := [ "-" ] Term { ("+" | "-") Term }
Term       := Factor { ( "*" | "/" ) Factor }
Factor     := RealNumber | "(" Expression ")"
RealNumber := Digit{Digit} | [Digit] "." {Digit}
Digit      := "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"```

Since we need to support priority of operations, we are putting the addition and subtraction (and negation) on top level of our grammar and therefore they will be evaluated at the end after the recursive calls to lover level terminal symbols are parsed and evaluated – because we are building a “descent” parser that goes from top level concepts towards lower ones.

Lets analyze each row of our expression.

In Expression definition row we have introduced non-terminal symbol Term that represents the part of expression that is on top level and has addition or subtraction for operation:

```Expression := [ "-" ] Term { ("+" | "-") Term }
```

Inside of Term definition we are introducing the Factor non-terminal symbol that represents part of expression that has multiplication or division for operation:

` Term       := Factor { ( "*" | "/" ) Factor }`

In the Factor we are already expecting the ending symbol of our expression – the RealNumber, its the first one we can start directly evaluating. If not RealNumber then we expect another Expression in parenthesis:

``` Factor     := RealNumber | "(" Expression ")"
```

After that we define what RealNumber is – its either a digit followed by more digits or its a digit with decimal point followed by more decimal places:

`RealNumber := Digit{Digit} | [Digit] "." {Digit}`

#### The Parser

Since we defined the grammar, writing the parser is almost mechanical process. We just start from the top level concepts in the grammar and create method for each element we have (Term, Factor, RealNumber, Digit etc) and call them one after the other or recursively.

Here is our entry method called Parse that starts the parsing and handles the first row of our grammar, the Expression row:

```        // Expression := [ "-" ] Term { ("+" | "-") Term }
public double Parse()
{
var isNegative = NextIsMinus();
if (isNegative)
GetNext();
var valueOfExpression = TermValue();
if (isNegative)
valueOfExpression = -valueOfExpression;
while (NextIsMinusOrPlus())
{
var op = GetTermOperand();
var nextTermValue = TermValue();
if (op is PlusToken)
valueOfExpression += nextTermValue;
else
valueOfExpression -= nextTermValue;
}
return valueOfExpression;
}
```

You can see that we are just following the grammar: we handle the negation and then call the TermValue method to get the next Term and then while there are plus or minus operators, we continue getting the next term again (again by calling TermValue) and then based on the extracted operator we decide should we add or subtract those two Term values. We repeat this as many as times as needed and accumulate the total result and then return it – that’s all.

Lets drill down to see the TermValue method:

```        // Term       := Factor { ( "*" | "/" ) Factor }
private double TermValue()
{
var totalVal = FactorValue();
while (NextIsMultiplicationOrDivision())
{
var op = GetFactorOperand();
var nextFactor = FactorValue();

if (op is DivideToken)
totalVal /= nextFactor;
else
totalVal *= nextFactor;
}

return totalVal;
}
```

Here its again similar process: but we are handling the second row of our grammar. We call the FactorValue method to parse the next Factor and then while we encounter tokens for multiplication or division we again call FactorValue to get the second Factor and based on the operation we divide or multiply. And as many as times this happens we are accumulating the result in the totalVal variable, and returning it at the end.

Final important method we need to implement for parser is the FactorValue method:

```        // Factor     := RealNumber | "(" Expression ")"
private double FactorValue()
{
if (NextIsDigit())
{
var nr = GetNumber();
return nr;
}
if (!NextIsOpeningBracket())
throw new Exception("Expecting Real number or '(' in expression, instead got : " + (PeekNext() != null ? PeekNext().ToString()  : "End of expression"));
GetNext();

var val = Parse();

if (!(NextIs(typeof(ClosedParenthesisToken))))
throw new Exception("Expecting ')' in expression, instead got: " + (PeekNext() != null ? PeekNext().ToString() : "End of expression"));
GetNext();
return val;
}
```

This one is even simpler. Based on our grammar row we know that we can expect either our RealNumber, or Expression in parenthesis.
So we check if next Token in the expression is token with number (NumberConstatToken), and if it is we just extract its value by calling GetNumber method and return it.

If next token is not number, then we know we expect the opening bracket (we throw exception if not) and here we recursively call the main Parse method (from which the execution started in the first place) to parse the next expression and so on, and on, and on until we unwind the expression completely ending up with the calculated result for the whole expression.

I wont go through all the helper methods that are defined and used there since they are trivial and not really interesting – you can always check out the full source on GitHub. Important takeaway is that it is really straightforward to implement the parser once you define the grammar properly – this opens up endless possibilities…

#### Looking ahead

You probably noticed that in the code i’m able to check if next symbol in the expression is of certain type – this is because i implemented simple TokensWalker class which allows me to peek the next token without consuming it:

```    public class TokensWalker
{
private readonly List<Token> _tokens = new List<Token>();
private int _currentIndex = -1;

public bool ThereAreMoreTokens
{
get { return _currentIndex < _tokens.Count - 1; }
}

public TokensWalker(IEnumerable<Token> tokens)
{
_tokens = tokens.ToList();
}

public Token GetNext()
{
MakeSureWeDontGoPastTheEnd();
return _tokens[++_currentIndex];
}

private void MakeSureWeDontGoPastTheEnd()
{
if (!ThereAreMoreTokens)
throw new Exception("Cannot read pass the end of tokens list");
}

public Token PeekNext()
{
MakeSureWeDontPeekPastTheEnd();
return _tokens[_currentIndex + 1];
}

private void MakeSureWeDontPeekPastTheEnd()
{
var weCanPeek = (_currentIndex + 1 < _tokens.Count);
if (!weCanPeek)
throw new Exception("Cannot peek pass the end of tokens list");
}

public bool IsNextOfType(Type type)
{
return PeekNext().GetType() == type;
}
}
```

#### May the source be with you

This concludes our not so long voyage through Recursive Descent Parsers. Hopefully i was able to interest some of you to start playing with these concepts. Now you can go and extend this and build a new calculator application, better than the built-in one that came with your beloved OS.

If you want to see the full source of this parser with all the unit tests, its available in my ArithmeticExpressionParser GitHub repo.

# Recursive Descent Parser with C# – Boolean logic expressions

In previous post we gave brief introduction on Recursive Descent Parsers and we implemented parser that was able to parse and calculate simple arithmetic expressions with addition and subtraction.

#### To be (True) or !(To be True)?

This time we will try to tackle little bit more complex example that will parse and evaluate Boolean logic expressions that will include negation and parenthesis.

Examples of expressions we want to be able to parse and evaluate are:

• True And True And False
• True
• !False
• (!(False)) and (!(True) etc

Let’s assemble a EBNF grammar for this type of expressions:

```Expression      := [ "!" ] <Boolean> { BooleanOperator Boolean }
Boolean         := BooleanConstant | Expression | "(" <Expression> ")"
BooleanOperator := "And" | "Or"
BooleanConstant := "True" | "False"```

You can see that our Terminal Symbols are “And”, “Or” (BooleanOperator) and “True”, “False” (BooleanConstant) and off course  “!” and parenthesis.

Expression can have optional negation symbol “!” and then Boolean (which can be BooleanConstant or Expression or Expression in parenthesis).

Every next Boolean expression is optional but if its there, it must be preceded by BooleanOperator so that we can parse the final value by combining it with previous Boolean value. Obviously we will have some recursion there, but more on that later when we start implementing the parser.

#### Always Tokenize everything!

Before looking into the parser, we have to implement the Tokenizer class that will parse the raw text of the expression, tokenize it and return IEnumerable<Token> so that our parser can have less to worry about.

Here is the Tokenizer class:

```    public class Tokenizer
{
private readonly StringReader _reader;
private string _text;

public Tokenizer(string text)
{
_text = text;
_reader = new StringReader(text);
}

public IEnumerable<Token> Tokenize()
{
var tokens = new List<Token>();
while (_reader.Peek() != -1)
{
while (Char.IsWhiteSpace((char) _reader.Peek()))
{
_reader.Read();
}

if (_reader.Peek() == -1)
break;

var c = (char) _reader.Peek();
switch (c)
{
case '!':
tokens.Add(new NegationToken());
_reader.Read();
break;
case '(':
tokens.Add(new OpenParenthesisToken());
_reader.Read();
break;
case ')':
tokens.Add(new ClosedParenthesisToken());
_reader.Read();
break;
default:
if (Char.IsLetter(c))
{
var token = ParseKeyword();
tokens.Add(token);
}
else
{
var remainingText = _reader.ReadToEnd() ?? string.Empty;
throw new Exception(string.Format("Unknown grammar found at position {0} : '{1}'", _text.Length - remainingText.Length, remainingText));
}
break;
}
}
return tokens;
}

private Token ParseKeyword()
{
var text = new StringBuilder();
while (Char.IsLetter((char) _reader.Peek()))
{
text.Append((char) _reader.Read());
}

var potentialKeyword = text.ToString().ToLower();

switch (potentialKeyword)
{
case "true":
return new TrueToken();
case "false":
return new FalseToken();
case "and":
return new AndToken();
case "or":
return new OrToken();
default:
throw new Exception("Expected keyword (True, False, And, Or) but found "+ potentialKeyword);
}
}
}
```

Not much happening there really, we just go through the characters of the expression, and if its negation or parenthesis we return proper sub classes of Token and if we detect letters we try to parse one of our keywords (“True”, “False”, “And”, “Or”).
If we encounter unknown keyword we throw exception to be on the safe side. I deliberately did not do much validation of the expression in this class since this is done later in the Parser – but nothing would stop us from doing it here also – i will leave that exercise to the reader.

#### The Parser

Inside of our parser we have main Parse method that will start the process of parsing the tokens, handle the negation, and continue parsing sub-expressions while it encounters one of the OperandTokens (AndToken or OrToken).

```        public bool Parse()
{
while (_tokens.Current != null)
{
var isNegated = _tokens.Current is NegationToken;
if (isNegated)
_tokens.MoveNext();

var boolean = ParseBoolean();
if (isNegated)
boolean = !boolean;

while (_tokens.Current is OperandToken)
{
var operand = _tokens.Current;
if (!_tokens.MoveNext())
{
throw new Exception("Missing expression after operand");
}
var nextBoolean = ParseBoolean();

if (operand is AndToken)
boolean = boolean && nextBoolean;
else
boolean = boolean || nextBoolean;

}

return boolean;
}

throw new Exception("Empty expression");
}
```

Parsing of the sub-expressions is handled in the ParseBoolean method:

```       private bool ParseBoolean()
{
if (_tokens.Current is BooleanValueToken)
{
var current = _tokens.Current;
_tokens.MoveNext();

if (current is TrueToken)
return true;

return false;
}
if (_tokens.Current is OpenParenthesisToken)
{
_tokens.MoveNext();

var expInPars = Parse();

if (!(_tokens.Current is ClosedParenthesisToken))
throw new Exception("Expecting Closing Parenthesis");

_tokens.MoveNext();

return expInPars;
}
if (_tokens.Current is ClosedParenthesisToken)
throw new Exception("Unexpected Closed Parenthesis");

// since its not a BooleanConstant or Expression in parenthesis, it must be a expression again
var val = Parse();
return val;
}
```

This method tries to parse the simplest BooleanValueToken, then if it encounter OpenParenthesisToken it handles the Expressions in parenthesis by skipping the OpenParenthesisToken and then calling back the Parse to get the value of expressions and then again skipping the ClosedParenthesisToken once parsing of inner expression is done.

If it does not find BooleanValueToken or OpenParenthesisToken – method simply assumes that what follows is again an expression so it calls back Parse method to start the process of parsing again.

#### To be logical is to be simple

As you see, we implemented the parser in less then 90 lines of C# code. Maybe this code is not particularity useful but its good exercise on how to build parsing logic recursively.

It could be further improved by adding more logic to throw exceptions when unexpected Tokens are encountered but again – i leave that to the reader (for example expression like “true)” should throw exception, but in this version of code it will not do that, it will still parse the expression correctly by ignoring the closing parenthesis).

#### Tests

Here are some of the Unit Tests i built to test the parser:

```        [TestCase("true", ExpectedResult = true)]
[TestCase(")", ExpectedException = (typeof(Exception)))]
[TestCase("az", ExpectedException = (typeof(Exception)))]
[TestCase("", ExpectedException = (typeof(Exception)))]
[TestCase("()", ExpectedException = typeof(Exception))]
[TestCase("true and", ExpectedException = typeof(Exception))]
[TestCase("false", ExpectedResult = false)]
[TestCase("true ", ExpectedResult = true)]
[TestCase("false ", ExpectedResult = false)]
[TestCase(" true", ExpectedResult = true)]
[TestCase(" false", ExpectedResult = false)]
[TestCase(" true ", ExpectedResult = true)]
[TestCase(" false ", ExpectedResult = false)]
[TestCase("(false)", ExpectedResult = false)]
[TestCase("(true)", ExpectedResult = true)]
[TestCase("true and false", ExpectedResult = false)]
[TestCase("false and true", ExpectedResult = false)]
[TestCase("false and false", ExpectedResult = false)]
[TestCase("true and true", ExpectedResult = true)]
[TestCase("!true", ExpectedResult = false)]
[TestCase("!(true)", ExpectedResult = false)]
[TestCase("!(true", ExpectedException = typeof(Exception))]
[TestCase("!(!(true))", ExpectedResult = true)]
[TestCase("!false", ExpectedResult = true)]
[TestCase("!(false)", ExpectedResult = true)]
[TestCase("(!(false)) and (!(true))", ExpectedResult = false)]
[TestCase("!((!(false)) and (!(true)))", ExpectedResult = true)]
[TestCase("!false and !true", ExpectedResult = false)]
[TestCase("false and true and true", ExpectedResult = false)]
[TestCase("false or true or false", ExpectedResult = true)]
public bool CanParseSingleToken(string expression)
{
var tokens = new Tokenizer(expression).Tokenize();
var parser = new Parser(tokens);
return parser.Parse();
}
```

Full source code of the whole solution is available at my BooleanLogicExpressionParser GitHub repo.

Stay tuned because next time we will implement parser for more complex arithmetical expressions.

# Introduction to Recursive Descent Parsers with C#

#### Parser? Aren’t parsers utterly boring?

Well no, quite the opposite. Lately i have been solving some of the programming challenges on talentbuddy and bumped into task to create parser and solver for simple arithmetic expressions in string format, something like this: “(2+2)-(3-(6-5))-4″.

On first thought this seems trivial, but only until the moment you start implementing it. If you are doing it the wrong way, for example by using regular expressions, you can bump into some interesting problems, and also develop a solution that works for most cases but then fails on edge cases etc.

#### The proper way

Fortunately there are proper ways to do this, and one of them is building a Recursive Descent Parser. As the name implies, this parser will use a Top-Down approach and start breaking the expression into smaller pieces but in recursive way. In order to be able to build a proper parser we first need to define a grammar of the expressions we want to parse.

For defining grammars we can use Backus-Naur Form or Extended Backus-Naur Form.

If we manage to define the grammar properly, then implementing the parser is almost a mechanical process, and this is what i really like about this approach.

In this post we will build very simple Recursive Descent Parser for basic aritmetic operations of addition and subtraction of integers. Later we will tackle some more interesting scenarios, but for this post we want to keep things simple.

So the examples of expressions we want to parse could be:

• “1”
• “1+100″
• “1+2+3+44″
• “100-99+1″ etc

#### Defining the grammar

So how would our grammar in EBNF would look like?

```Expression := Number {Operator Number}
Operator   := "+" | "-"
Number     := Digit{Digit}
Digit      := "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"```

Grammar above tells us that we are defining expressions that can contain numbers and operators.

Each Expression can contain a single integer Number or this number can be followed by optional set of Operator and then another Number must follow. Note the curly brackets around the {Operator Number} which means that this part can repeat zero or more times.

Then we continue and define what Operator could be (+ or -) and then we define that Number is just a Digit followed by zero or more Digits (again we use curly braces to define optional repetition of digits in integer number).

At the end we define that Digit is number from 0 to 9.

With this we defined our grammar and its vocabulary – and creating a parser should be simple, right? Well almost

#### Tokens and Tokenizers

First there is another small issue we need to handle here. Our input expressions will be in string format, and we need to parse them into something that our Parser will understand in order to abstract the raw character processing – we don’t want to string processing inside of Parser this would be bad practice.

This is where idea of Tokens comes into play. We will define tokens for each part of our grammar. We can have abstract Token class, and other tokens will inherit it.

Then we will have base OperatorToken that will be inherited by PlusToken and MinusToken, and finally we will have NumberConstantToken for our numbers.

Token classes will just be a simple marker classes with almost no functionality inside except for the NumberConstantToken which has to hold the actual value.

``` public abstract class Token
{
}

public class OperatorToken : Token
{

}
public class PlusToken : OperatorToken
{
}

public class MinusToken : OperatorToken
{
}

public class NumberConstantToken : Token
{
private readonly int _value;

public NumberConstantToken(int value)
{
_value = value;
}

public int Value
{
get { return _value; }
}
}
```

Now that we defined our Tokens, lets build a PlusMinusTokenizer class that will transform the raw string of the expression into a sequence of Tokens that our Parser can then elegantly work with:

```    public class PlusMinusTokenizer
{
private StringReader _reader;

public IEnumerable<Token> Scan(string expression)
{
_reader = new StringReader(expression);

var tokens = new List<Token>();
while (_reader.Peek() != -1)
{
var c = (char) _reader.Peek();
if (Char.IsWhiteSpace(c))
{
_reader.Read();
continue;
}

if (Char.IsDigit(c))
{
var nr = ParseNumber();
tokens.Add(new NumberConstantToken(nr));
}
else if (c == '-')
{
tokens.Add(new MinusToken());
_reader.Read();
}
else if (c == '+')
{
tokens.Add(new PlusToken());
_reader.Read();
}
else
throw new Exception("Unknown character in expression: " + c);
}

return tokens;
}

private int ParseNumber()
{
var digits = new List<int>();
while (Char.IsDigit((char) _reader.Peek()))
{
var digit = (char) _reader.Read();
int i;
if (int.TryParse(Char.ToString(digit), out i))
{
digits.Add(i);
}
else
throw new Exception("Could not parse integer number when parsing digit: " + digit);
}

var nr = 0;
var mul = 1;
digits.Reverse();
digits.ForEach(d =>
{
nr += d*mul;
mul *= 10;
});

return nr;
}
}
```

As you can see code is very simple and for given string expression it returns IEnumerable<Token>. There is also a part there that converts sequence of digits into into integer but we all know that so lets move on.

#### Parsing is Fun!

Now we finally come to the interesting part. Our parser should start from the top of our grammar and parse Expression, then inside of it parse the Number, then Operator then again Number etc.

So lets first examine the ParseExpression method:

```        private int ParseExpression()
{
var number = ParseNumber();
if (!_tokens.MoveNext())
return number;

if (_tokens.Current is OperatorToken)
{
var op = _tokens.Current;
_tokens.MoveNext();

var secondNumber = ParseNumber();
if (op is PlusToken)
{
return number + secondNumber;
}
if (op is MinusToken)
return number - secondNumber;

throw new Exception("Unsupported operator: " + op);
}

throw new Exception("Expecting operator after number, but got " + _tokens.Current);
}
```

Its barely 30 lines of code that first calls our ParseNumber method to get first number of the expression, and then it checks if next Token is OperatorToken, and if so, it calls the ParseNumber again to get second number and then based on the type of the Operator performs the addition or subtraction and returns the resulting integer.

Note that Exception is thrown if some unexpected token is encountered, so that we can know when we have invalid expression. We could have also done this inside of the Tokenizer but i wanted to have this logic just in one place.

Now let’s see the ParseNumber method:

```        private int ParseNumber()
{
if (_tokens.Current is NumberConstantToken)
{
return (_tokens.Current as NumberConstantToken).Value;
}

throw new Exception("Expected a number constant but found " + _tokens.Current);
}
```

As you see this method just returns the value of the number from our Token.

I told you this is gonna be simple

OK lets now see the main method of the Parser that uses the methods explained above:

```        public int Parse()
{
var result = 0;
while (_tokens.MoveNext())
{
result = ParseExpression();

if (_tokens.MoveNext())
{
if (_tokens.Current is OperatorToken)
{
var op = _tokens.Current;

var secondNumber = Parse();
if (op is PlusToken)
{
return result + secondNumber;
}
if (op is MinusToken)
return result - secondNumber;

throw new Exception("Unsupported operator: " + op);

}
throw new Exception("Expecting operator after expression, but got " + _tokens.Current);
}
}

return result;
}
```

This is where it all happens, the Parse method calls ParseExpression to get first Expression, and then – if there are more tokens and first one is OperatorToken, we call recursively again Parse and therefore parse next expression and get its result, and then we do the operation based on the Operator, and then inside of that call if needed we call Parse again recursively, and then the next one, and way we go down the rabbit hole…

I told you this was fun

#### Tests

Whole solution is built with Test-First because the idea of Parsers and Tokenizers fit very well with unit testing. If you are interested in this check out the project PlusMinusParser.Tests where there are tests for both the Tokenizer and the Parser. All of them pass an input expressions and expect certain results – integer as solution of the expression (for Parser) or list of Tokens (for Tokenizer).

Here are some tests for Parser (Note that im using NUnit’s TestCase attribute):

```    [TestFixture]
public class PlusMinusParserUnitTests
{
[TestCase("1", ExpectedResult = 1)]
[TestCase("2", ExpectedResult = 2)]
[TestCase("1+1", ExpectedResult = 2)]
[TestCase("1+1+1", ExpectedResult = 3)]
[TestCase("1-1", ExpectedResult = 0)]
[TestCase("0-0", ExpectedResult = 0)]
[TestCase("0-1", ExpectedResult = -1)]
[TestCase("1+2+3+4+5+6", ExpectedResult = 21)]
[TestCase("100-100", ExpectedResult = 0)]
[TestCase("100-100+1", ExpectedResult = 1)]
[TestCase("100-100+100", ExpectedResult = 100)]
[TestCase("1 2", ExpectedException = typeof(Exception))]
[TestCase("+", ExpectedException = typeof(Exception))]
[TestCase("++", ExpectedException = typeof(Exception))]
[TestCase("--", ExpectedException = typeof(Exception))]
[TestCase("+-", ExpectedException = typeof(Exception))]
[TestCase("-+", ExpectedException = typeof(Exception))]
[TestCase("-", ExpectedException = typeof(Exception))]
[TestCase("1-1 2", ExpectedException = typeof(Exception))]
[TestCase("10-100", ExpectedResult = -90)]
public int CanParseExpressions(string expression)
{
var tokens = new PlusMinusTokenizer().Scan(expression);
var parser = new PlusMinusParser(tokens);
var res = parser.Parse();
return res;
}
```

#### Where next?

Well now that we have a solid basic understanding on how to build simple parsers, we can go wild and invent different grammars and build parsers for them. Having this in your tool-belt can be very handy when you encounter tasks that need to parse text.

In one of the next posts i will implement some more complex parsers so stay tuned…

If you want to see the full source code check out my PlusMinusParser repository on GitHub.

# Introducing the Unit Testing Context Pattern

## Another pattern?

Well yes. I write unit and integration tests almost every day and along the way i learned all kinds of different tricks and gotchas on how to be more productive and how to write less fragile tests.

But one of the patterns that emerged i never saw in the code of other people so i decided to share it here since i find it very useful.

I call it Testing Context Pattern and – unlike it’s name – its very simple.

Idea is to create in your Test Fixture a private class called (you guessed it) TestContext and put all the mocks/instances needed for testing the current class and then create instance of that class we test by using those mocks and then also expose all of that as public fields of the TestContext.

That way we have all we need for testing in one place and we can start having fun!

So if we are testing class WebPageDownloader that needs two more entities to function (IUrlPermissioner and IUrlRetriever) then we create class TestContext like this:

```        private class TestContext
{
public Mock<IUrlPermissioner> PermissionerMock;
public Mock<IUrlRetriever> UrlRetrieverMock;
public WebPageDownloader Downloader;
}
```

Notice here that we expose the mocks of the dependencies on the context (I’m using Moq testing framework but you can choose any other you like) this is very important because later in our tests we can then give further setups/expectations to those mocks that are used inside test class.

Next we create a private method on test fixture that creates instance of context for us, initializes it with all the mocks needed for testing and the tested class instance itself and returns it (this is to avoid creating this in each test):

```        private TestContext CreateContext()
{
var ctxt = new TestContext()
{
PermissionerMock = new Mock<IUrlPermissioner>(),
UrlRetrieverMock = new Mock<IUrlRetriever>(),
};

ctxt.Downloader = new WebPageDownloader(ctxt.PermissionerMock.Object, ctxt.UrlRetrieverMock.Object);

return ctxt;
}
```

As you see i create all the mocks that our tested class needs, then i instantiate it by passing mocked instances into its constructor and then i save mocks and target class in the context for usage in further tests.

## Testing Context in action

So now in each test i call CreateContext method to get fresh instance of TestContext and start testing my target class.
Good thing about this is that in the TestContext we have all the mocks of dependencies used to create the tested class, so we can still manipulate them, mock out some specific methods for each test, and also we can check later in the test if the mocks were used in proper way, check what methods the target class invoked on them etc.

Here is an example of test that checks if our class throws exception for URl that is not permitted by IUrlPermissioner:

```        [Test]
[ExpectedException(typeof(SecurityException))]
public void Download_WhenNotPermitted_Throws()
{
var ctxt = CreateContext();

var badUrl = "http://www.SomeBadUrl";

// arrange
ctxt.PermissionerMock.Setup(a => a.IsUrlAllowed(badUrl)).Returns(false);

// act
ctxt.Downloader.Download(badUrl);

// assert we don't need to do since we have ExpectedException attribute
}
```

As you can see in the test we just call the CreateContext method to get fresh context, then we use the mocks from the context to setup our expected calls and return values, and then we invoke actual method on the class we are testing and then we expect the exception (via ExpectedException attribute that we placed on the test method)

Here is little more complex scenario where we setup multiple mock interactions with our class and then expect return result to be correct:

```        [Test]
public void Download_WhenAllowed_ShouldReturnWebpageGotViaRetriever()
{
var ctxt = CreateContext();

var OkUrl = "http://www.SomeOkUrl";
var OkUrlContent = "Some Web Page";

// arrange
ctxt.PermissionerMock.Setup(a => a.IsUrlAllowed(OkUrl)).Returns(true);
ctxt.UrlRetrieverMock.Setup(a => a.Retrieve(OkUrl)).Returns(OkUrlContent);

// act
var result = ctxt.Downloader.Download(OkUrl);

// assert
Assert.AreEqual(OkUrlContent, result);
}
```

Another good thing here is that if you later refactor your target class and add/remove dependencies you can easily change TestContext and CreateContext method accordingly and none of your existing tests should fail to compile because of that, unlike the situation when you would do all this in each test.

As usually, you can download Visual Studio 2012 solution showing this in action if you are interested.

I hope this simple pattern can help someone in writing better tests.
If you have comments or if you are doing something similar in your tests leave a comment i would love to hear it.