Skip to main content

Posts

Showing posts from May, 2015

Testing Private Code

A common problem many people ask is - should you test private code? In short, you shouldn't. You should always test the public api of your code where possible. This is not always easy. Based on the context of the code in question there are a few options available.Don't TestEither don't test the private code or rely on manual testing. This will not be ideal in many cases, but if the code is covered in higher level tests you may be able to get away with it. If the code will be stable, short lived or low risk you can default to this option.Test via Public TestsSimply test the private code by adding assertions or verifications to exisiting public behaviour tests. If the setup requires a lot of work, many edge cases or much duplication you may want to avoid this technique.Make the Code PublicOnce public, the code is easily testable. Are we making this code public just for the sake of an automated test? Yes, but there are valid times to do this. Providing the behaviour is logica…

Mob Programming

I first saw this video of Mob Programming a couple of years back. Mob Programming is pair programming taken one step further, the whole team is based around a single machine. The developers rotate regularly and those who are not driving can add feedback, make suggestions or simply watch and learn. Everyone should be placed on a level playing field. I will admit to being highly sceptical of Mob Programming at first.I advocate walking skeletons to ensure we are on the "right path" when developing. We wanted to do these as a team, during our planning and tasking phase. I suggested mobbing rather than watching a solo developer on a projector and it turned out to be quite fun. We also learned a few new tricks such as keyboard shortcuts or IDE techniques along the way.There were a few rough edges, mainly due to the setup used. A laptop around a screen proved difficult and this in turned seemed to put pressure on individuals. In repeat sessions we have used a dedicated space, with …

Walking Skeleton

A Walking Skeleton is the thinnest possible slice of new functionality that can be delivered end to end. The term "walking" refers to the ability for the feature to "stand on its own". You should be able to deploy a Walking Skeleton and demonstrate it. Just like a human skeleton is an incomplete body, a Walking Skeleton is an incomplete piece of software with many internals stubbed, not implemented or consisting of basic functionality.While the software won't do much it provides rapid feedback. It allows your build and deploy pipeline to be set up if not already in place. More importantly it gives developers a framework or scaffold to work with.Production of a Walking Skeleton should be fast. Components such as which objects to introduce should ideally be developed top down, however the actual direction each solution takes will vary. Some design will still be required, but the choice of patterns or implementation details should be deferred where possible. Core …

Tasking in Software Development

Tasking is core part of XP, Kanban, Scrum and other software development methodologies. It is required when more than one developer is working on a feature. I consider it to be the most wasteful part of the development process as practiced in the mainstream.Tasking typically involves the team sitting around a machine/desk/whiteboard/projector. From past experience this can take anywhere from an hour up to a day or more. Engagement is often low and this process can be both mentally and physically tiring. During which many assumptions about what should be done is made.The end result is nothing but index cards, scribbled diagrams or other lightweight documentation. These artifacts are often transformed into digital versions.ProblemsThe foolish understanding is that now any developer can pick up a task and start work. This leads to dependent tasks being worked on in an independent manner. Team members then find themselves being impeded until a certain piece of code is in place. No amount …