On using static fixtures

In my current project we are using fixtures to pre-configure domain objects for testing purposes. A discussion with my team lead has surfaced some interesting implications of misusing fixtures.

In our domain we have a concept of Application and we have an ApplicationFixture class that can createApplication() which returns an instance of applications pre-configured for some functional tests. The issue with this setup is that it makes it look like we can reuse this fixture not only in functional tests, but also in any other types of tests (eg. integration) which require an application. This may not be appropriate as the fixture could be introducing irrelevant dependencies/configuration to the integration tests.

In conclusion: Using fixtures is fine as long as they are used for the purpose they've been pre-configured for. Personally I like the idea of reflecting the purpose/test level of the fixture in its name.

Why getters and setters are evil

"Don't ask for the information you need to do the work; ask the object that has the information to do the work for you" is the suggestion to cast away the evil associated with getters and setters as proposed by Allen Holub, JavaWorld.com. Full article is available here.

The simplest thing that could possibly work

More senior devs on my team follow this principle with passion. After seeing it applied for a bit it started to remind me a lot of mathematical simplification exercises I did in school (Gosh, I never thought I'd end up using the concept). It works like this: If you see duplication - remove it; if a class is too light on functionality - merge it with another relevant class. To think of it, it makes perfect sense as when a code base that is rid of duplication and unnecessary complexity there are less places we'd have to go to change it.

On Rhythm when Pair Programming

I was paring with Dave today. And before this time I felt we couldn't quite get the rhythm going.. Some times I felt sort of resistance to my questions, at others I'd see little interest from his side, like he was sorta patiently enduring our time paring and my slower pace of coding, as he is a more senior dev and I like to take time to actually understand what going on.

Anyways, today we had a bit of a breakthrough; he came up with this idea of "pong". It works as follows: one of us would write a test, then other would make the test pass and write another test, then the keyboard will return to the original dev who would make the second test pass and write the third test, and so on and so forth. Aiming to hand over the keyboard the paring dev as quickly as possible.

I felt it worked well for us, cause it created a certain rhythm, helped me to be more engaged cause I knew that the keyboard will return to my hands relatively soon. This approach is certainly something I should do more of!