Test Driven Development (TDD) is often reduced to the three phases
Red – write a test
Green – make it run
Refactor – clean up code
There is nothing wrong about these three steps. But there is more involved in test-driving your development.
Test Driven Development (TDD) is often reduced to the three phases
Red – write a test
Green – make it run
Refactor – clean up code
There is nothing wrong about these three steps. But there is more involved in test-driving your development.
I must say I’m really a huge fan of Moq. Moq is steady growing and the developer community is quite impressive in inventing new features and extensions. I recently ran over a nice feature suggestion placed in a private branch from moq. The branch belongs to Brian J. Cardiff. I suggest you check also his blog out! The feature brain suggested is an extension method which allows to do sequential setups. The sequential setup allows to specify in a fluent way for example different return types...
The first post of this series gave a quick overview over the event tester usage, the last post gave a deep dive into some part of the event tester code. When talking about line numbers or certain code expression I’m always referring to the code provided in the last post. When talking about the expression tree construction in the last post the last thing we got into was the build up of the if/then/else expression. After building up the if/then/else expression we need to build the...
In my last post I gave a quick overview over the event tester usage and how you could benefit from such a component. In this post I want to show you the source code of my event tester implementation and give you a short dive into the expression tree magic that is happening behind the scenes. This time I show you first not only portions of the code but the whole code in advance annotated with line numbers. My explanations will point to line numbers in the code below.
I always wanted to get my hands dirty with a little expression tree magic but never had the time to do so. When test driving code of a component you are currently working on you might feel in the middle of the “Do a little change, let it fail, make it green” process that your component needs an event which is publicly visible and can be subscribed by clients. But how would you test that the event is fired on your component’s interface? I’ll show you how this is normally...
In my first post (link) I’ve explained what StyleCop is and how you can start with your own StyleCop rules. We will now dig a little bit deeper into the jungle of StyleCop….
Lately, I asked myself why I like Scrum most. I’m a big fan of Scrum because of a lot of things. So I asked myself: “What is the root cause of all these”. I tracked it down to two main things: Focus Feedback I’ll come back to that later. I’m also a big fan of Test Driven Development. Guess what, I performed a root cause analysis on TDD, too. And once again: Focus Feedback After that, I asked myself: “Are there other things I like with these root causes?”. Yes there are: Playing Volleyball and...
For those of you interested in TDD:
I’m speaking at the conference SET (Software Engineering Today) in Schlieren (Zurich) on Tuesday May 5th.
I’ll show the basics of the TDD cycle, benefits and pitfalls, and how you get started.
Link to SET 2009: SET 2009
Link to my session (german): TDD
Looking forward to some interesting discussions…
I’m often hearing thoughts about Test Driven Development from people not using it, which are not true (at least not 100%).
Therefore, I want to describe some of these myths here:
Writing unit tests is difficult and complex
Projects take longer because of the additional test code that has to be written
Not everything can be tested with unit tests. Therefore TDD cannot be used.
There is no need for architecture and design because TDD claims to evolve that from tests