ALT.NET Dublin

Chapter 6 was about test hierarchies and Organization. It goes through several practical tips.
It starts off by telling us about the importance of automating the running of tests, and we agree there.
It also recommends separating between slow and fast tests (this pretty much should be read as unit tests and integration test) so that when you are coding you are more likely to run the tests at all times. Lukewarm on this idea, in some projects might make sense, however you could run into the trap of most tests are integration tests => tests are not run often enough => system brakes even thou you have unit tests => trust in the unit test is broken. But I think we can all see the point of this.
I don’t understand why there is a (small) section about ensuring tests are part of source control , why wouldn’t you put that there?
Then there is some advice about the code organization and naming conventions around it. Including the case where you need to create a unit separately just for a particular area of the unit because you need to write many tests for it, in this case the unit test class is called for example LoginManagerTestsChangePassword as a complimentary set of LoginManagerTests.
Then we hit possibly the most important part of this chapter: Building the test API for your application, this section recommends the use of inheritance creating new utility classes and methods and making your API known to the developers you work with. This is probably the best part of this chapter. The three methods discussed are described in an ok manner, perhaps the examples (particularly the one for abstract test infraestructure test pattern) are not incredibly descriptive, however they do describe the ways to build your API and the reasons behind why you would
do and use the methods.

Summing up

Good things about this chapter
- Unit tests should be part of your build cycle
- Spelling out the fact you need t build and maintain you tests API

Bad:
- a bit verbose
- examples not great
- Style not consistent ( ie there is no pattern on explaining why something is good bad, so you cant compare like with like)

Hi all:

So the next meet up is the 17th of November at 7pm in Seagrass, however wondering if anyone wants to volunteer some talks? Please comment here

Cheers and Thanks

This chapter was about setting the basics on mocking.

It starts talking about interaction testing, and how when we are using mocks we want to make sure that certain interactions have occurred, and not necessarily the result ( that would be state based testing).

Then we move on to the definition of a mock object, in other words it means that we define if the test has passed or failed based on the mock object.

In general it was a really short chapter, maybe it could have been merged with chapter 3.

We discussed this chapter the 5th of October.

Chapter 3 is about stubs. The meat of this chapter is on the techniques used to break dependencies.

To use most of these techniques you need to extract an interface and inject a stub into the class under test. The options presented in the book are:

- Receive an interface at the constructor level
- Receive an interface as a property
- Getting a stub just before the method call (using factories)

The first and second options seem to be the ones we all seem to be more used to, and we also agreed on the fact that is good to use the first method when making a dependency required and using the second method ( by properties) when the dependency is optional.

IoC containers are mentioned but there is little or no mention on how to use them when testing.

The third option we didn’t really see the point, it seemed over complicating something that can be simpler, and we couldn’t see the advantage of using this technique, perhaps it is useful in Legacy scenarios? In the book, he (Roy Osherove) mentions that this seems cumbersome at the beginning but it becomes more natural. I find it hard to understand the advantages of this method, I would really appreciate other peoples comments on this.

Then there is some content on Extract and Override, the idea of overriding a virtual method  to be able to obtain a result to make the system testable seems to me somewhat more natural, however, I still think there is a lot of investment (code wise) and small return, it also makes your test harder to read.

There is another section of the chapter when it talks about encapsulation, using internals and [internalsVisibleTo] and in general, different ways to open up your code enough to make it testable hiding bits of the API that you don’t consider should be public.

Not the most straight forward chapter to read but plenty to make you think.

Comments on this chapter from David:

This is another idea for an open source project. Quite simply it’s a web app that allows you to manage a kanban board.

Kanwhat?

If you were around for Claudio’s presentation on 15th of September past, you already know what kanban is (at least as much as I do anyway ). For those that weren’t there, kanban is basically a mechanism that limits work in progress. Rather than time boxed iterations where you work on a batch of stories, in kanban stories are pulled through the system when there is capacity and (ideally) deployed when finished. This means that you can identify and eliminate bottlenecks early and provide more value to your customer.

Why?

I think this could be a nice project for us for a few reasons:

• It’s useful. I think this has potential to help a lot of people in the group with their day to day development efforts.
• It’s simple but with scope for growth. It should be fairly easy to get something useful up and running but I think there is also a lot of potential for spin off / supporting projects (Surface planning app anyone? I’m sure Martha could secure us some hardware for testing ).
• We have a very good customer in Claudio who is able to provide the knowledge of Kanban and how it should be applied.

So what would it look like?

Initially I see this being a fairly straightforward web app displaying a kanban board and allowing users to add stories and pull them through the system. I think we could then start to add lots of useful features for notifying, measuring lead/cycle time, identifying bottleneck, etc. I’d also like to see a nice rest api and possibly a rich client.

The competition

There are a few products out there already that provide kanban boards. None that I’m aware of are open source.

http://agilezen.com/

http://justkanban.com/

Further reading

http://www.limitedwipsociety.org

http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

What say you?

Let us know what you think in the comments.

Is there anyone that would like to help to build a .Net XMPP client library, open sourced under a commercial friendly licence? There are a few GPL and LGPL ones out there, but these aren’t suitable for mono, which I would like this library to support

While XMPP’s (aka Jabber) original goal was to have a open and federated instant messaging system it has changed in scope to be a more generalized and extensible messaging system for applications. An recent example being Google Wave. Ultimately I would like this project to lead into .Net XMPP server, and even perhaps a .Net implementation of Google’s wave protocol. As a protocol itself,  XMPP is fast, secure and extensible. From Google Wave: Another step toward XMPP powering the real time web:

XMPP is already at the heart of several cloud computing platform and is becoming increasingly popular as a glueing tool for various types of services around the world. It is gaining mindshare ans supporters as a near real time protocol to power the next generation of web services and applications.

For my own particular perspective, I am involved in building a S+S (SaaS if you like) product that has a requirement to display large amounts of data, of which may change rapidly at certain points of the day and have those changes pushed soft real-time to clients (desktop and web). This component will go into production and as such will have time invested in it.

There is a lot more to XMPP such as PUBSUB, SIP etc. but this point I’m really interested in getting the Core and Instant Messaging and Presence RFC’s implemented and take it from there. I’ve done a dev spike, and learned a number of things that should help is starting this of. Anybody interested in joining forces?