This is the presentation I gave at the conference Basta! in September 2012.
Before we can talk about Agile quality assurance, we have to make a step back and take a look …
… at the goals of Agile software development. Our Agile quality assurance strategy should support these goals:
Since I’m developing my current iOS app using test driven development, I thought I’d share some of the things I’ve learned in the process. I’ll be focusing on TDD at the unit test level and I’ll only be discussing writing unit tests for view controllers. The concepts discussed in this post can easily be extended so that unit tests cover all parts of an iOS application and not just the view controllers. Two key ingredients to successfully writing cohesive unit tests...
This is the presentation I gave at the .Net System Event by bbv Software Services AG in Lucerne in June 2012:
In my last post I showed the transformation from the generic repository to the unit of work pattern only. I received an interesting question in the comment section. Looks nice so far. But didn’t you mix up and simplify things a little bit too much here? For me the Repository is the separation of Domain Objects and Persistent Entities. It’s also a separation of the client from the used persistency technology (either NHibernate, EF, SharePoint, ADO.NET, WebService or whatever). As client side...
There are a lot of discussions going on about the repository pattern. I also started one at the last usergroup meeting together with Julie Lerman. Generally the generic repository is considered an anti pattern as stated by Greg Young, he offers a solution by applying a composition pattern to maximize code reuse. Mike from SapiensWork even calls it a complete anti pattern. Ayende calls it since a long time the new singleton. Ayende also suggests in his older articles to either use directly...
Imagine you need to code the following requirements:
When an exception is thrown the transaction must be rolled back
The thrown exception must be rethrown
The productive code could look like:
Now how would you write the requirements above in two separate unit tests? Here comes FluentAssertions into the play.
If you are familiar with hamcrest and JUnit the time will come when you have the need to create your own matchers. Creating your own matcher can be as simple as useful. One reason for creating your own matcher could be that your object is not a default object like a String or a Collection. And if you would like to get a more readable version of the assert for the next developer who has to read your test. Let’s make an example. If you have an object with two methods; “getName”...
cross-post from bbv blog
When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.
Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do.
Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience.
To get most out of pair programming, you first have to know your setup.
Do you program or do you already TDD? 🙂
If you prefer to do TDD you will love the eclipse plug-in called MoreUnit. It is as simple as powerful. All it does is executing tests from corresponding productive class and makes it very simple to change between them.
Just press Ctrl-J (like Jump) to jump from test to implementing class and the other way. Or press Ctrl-R (like Run) to run the test regardless if you are in the test or the implementation class.