Category: Unit Testing

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 Read More

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 Read More

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 Read More