CITCON London was a great success and I enjoyed the event thoroughly, for the first time since starting as a Software Developer I managed to get myself outside of the bubble I work in and actually see how I “should” be doing things.
I really enjoyed the Open Spaces format and it allowed us to have a much more open discussion as everyone was acting like peers as opposed to a single person being at the head of the crowd after giving a keynote lecture. It really allowed us to communicate our ideas and talk about what we really wanted to talk about.
Having said that I came away thinking that I must be really stupid, knowing that we must be doing some things wrong, but still not so sure what those things were. Some people seemed very willing just to dismiss problems I expressed by just saying I was doing things wrong without explaining why I was doing things wrong.
Having said that the sessions were very insightfully and informative and came away thinking that I knew a lot more people in the community.
session Round Up:
Session 1:
What is a good/unit test, what is continuous integration, testing vocabulary.
This session, one of only 3 that ran in the 9am slot on the Saturday was really one of the more insightful of all, and my personal favourite. I had proposed a topic discussing what would be the bounds that everyone saw to a unit test no longer being a unit test, and a couple of other titles got tagged on too.
The outcome from this hour, apart from my descent into humbleness, was the idea that there are no unit tests/system tests/integration tests that matter, the names are nothing, what matters is we have two types of tests with differing priorities:
-
Developer Tests:
These tests are run regularly, generally before any code change is checked in, and should give an idea that the code runs well with other peoples code, that you haven’t broken anything. The main priority of these tests is Speed, when I make a change I am unlikely to want to run tests that run slowly and slow down my thought process and productivity so a slow test would quickly become a non-executed test and quickly become redundant.
- Customer Tests
These tests are exactly what they say, can the software, does the software, do all the things the customer wants. These are by nature slower to run, and often mix automated tests (even in the domain language) with Manual Tests.
So we should not be banding around such verbose and technical terminology and instead focus on these two names for any test also sometimes a test can be in both sets. hmmmm
Also a discussion on the merits of mocking and I
was quite surprised to see how many people didn’t use mocking frameworks but instead just hard coded mock objects…
Session 2:
End to End, where do the ends of testing lie?
This session saw a group of us discussing where do we control configuration management and where/how we prioritise tests. A discussion formed, mainly about how we should make sure that we mitigate and identify certain risk points in code, and a discussion of how the issues differed between in-house bespoke developers or product developers.
Session 3:
Getting the design benefits from testing.
This session was all about how modern coders/developers have taken on Test Driven Development and believed they were matching good design principals by default. However, there seems (from experience in the room) to be a lot of people who do not understand some basic principals of Object Orientated design..
I have to say I sat in this room and wrote “I am dumb” on a piece of paper to remind myself to go and brush up on my techniques, mainly because some of the terminology I just hadn’t heard… although since looking them up I actually found my coding practices generally follow them.
Session 4:
Low friction CI
This session was all about how to get a nice and easily configurable build that doesn’t use up all your time. I came away thinking that our build process is much to complex, and that I must look at speeding the whole thing up/striping the build down to it’s bare essentials. Something to do in the lead up to Christmas.
Session 5:
My brain was hurting so I decided to take a break here
Session 6:
FIT for fun and profit
I have to say I didn’t get a huge amount out of this session, mainly because I seemed to be one of only a couple of people using FIT in earnest on a project, so I took to the front and showed the others how we had FIT integrated into our build and had FITNESSE set up to control all our story tests. My demo was bad, mainly because I wasn’t expecting to do it, but hopefully next time there will be a couple more groups seeing the benefit from FIT.
technorati tags:CITCON, CITCONLONDON, Testing
Blogged with Flock