Mastering Design Patterns

WOW. This talk was excellent. The room was packed with standing room only available in the back. Robert C. Martin went through a number of common design patterns. There is no reason to me trying to summarize them all, just get the book. In the talk we went over the design patterns:

• Adapter
• Strategy
• Template
• State (two level, and three level)
• Observer
• Model View Controller
• Model Presenter
• Command
• Actor Model

This was an excellent talk.

http://www.objectmentor.com

Intel

Mark and I made a quick trip to Intel just before lunch and toured the museum.

Brian Is Sad

A talk I wanted to go to this morning in the Design and Modelling track was cancelled. So I went with Mark to the “Better Test Design” talk on writing unit tests instead. Now it is lunch hour and I just found out the talk I wanted to attend this afternoon called “Prefactoring”, a presentation discussing many of the refactoring principles outlined in Martin Fowler’s book called “Refactoring”, was cancelled. I met the presenter last night, he seemed great, we chatted for a bit, to bad the presentation did not happen. So for my afternoon I will now be attending the sessions “Mastering Design Patterns” and “Principles and Practices of Scrum“. Mark and I had the chance to meet the presenter for this Scrum talk last night. It should be very interesting.

Some Cool Software

So while I was at the EXPO touring the software booths, I stopped by the Atlassian booth. This is the company that makes Jira and Confluence. They have a few other tools which look useful.

Fisheye (source repository viewer)

Crucible (code reviews)

EXPO Software Vendors

Mark and I went to the software vendors area tonight and made it to just about every booth in the place. Most than half of all the software tools being pitched were along the lines of helping with Agile project management, release management, and QA. Agile has been a big theme of this conference so it was no surprise to see so many different tools to help teams following Agile adopt the process more easily.

That’s me stopping by he Google booth!

Mark could not decide between the free pretzel or the the free hot dog.

The EXPO Floor

My haul for the nights work

TDD

During the talk on TDD (Test Driven Development) the loop of the TDD cycle was discussed. I realize some of you who have already read about this topic and are familiar with this cycle, but I just thought I would mention it.

The TDD Loop

1. Write a small test for new functionality
2. Write just enough code for the new functionality to pass the test
3. Confirm that the revised system passes all tests
4. Refactor to remove “code smells”
5. Confirm that the revised system still passes all tests

So the question came up during the talk “How do you know how many tests to write?”. The answer to this question was “Write as many tests as you feel are necessary to feel confident that the code functions as it is supposed to”.  Developers are very good at writing positive tests (tests that show the code does what it is supposed to), however developers need to learn to get into the mindset of writing negative tests (tests that exercise conditions that should not happen but might).

TDD is extremely useful and important. Part of the problem pointed out with adoption is that if developers are just told to write unit tests and use TDD but are never given a good explanation of “Why” it can cause resistance to moving in this direction.

Unit Testing Private Methods?

I was not going to go into anything too specific in the blog, just stick to general concepts, but I do have to mention one interesting point discussed today. There was a section of the lecture devoted to unit testing and the topic of writing unit tests for private methods was mentioned. So the question was “Should you write unit tests for private methods” and the answer was NO.

Basically, a class has an interface of public methods. Those public methods use private methods. You write test cases for the public methods to ensure all functionality the class provides is covered by tests. If you need to write unit tests specifically for the private methods, then your test cases for the public methods are probably not covering all cases, and if they do, then the tests for the private methods are just duplicates of the public method test cases. One of the main problems with unit tests on private methods is that they make it difficult to refactor the inner workings of a class.

A developer should have the freedom to refactor the code within a class without needing re-write existing unit tests. We should be working at removing obstacles to refactoring and creating meaningful interfaces to our code that are both useful for development and testing.

Unit Testing

Part of the afternoon talk was on unit testing. There was a lot of material covered, so here are just a few topics discussed.

• Always remember that when you are adding unit tests you are adding more code that will now need to be maintained. Writing difficult to understand or brittle unit tests will cause future maintenance problems.
• Unit tests must be highly readable so that they will be easier for developers to understand in the future as they are also a form of documentation. Reading existing unit tests are also a great way for a developer to quickly understand how an existing class is supposed to be used.
• Never have a conditional or loop in a unit test, if you do, you must rewrite the test.
• Unit tests should always be simple.
• Unit tests are extremely important. TDD is important, but if there is an area of an application that is not currently covered by unit tests there is still a great deal of value in adding unit tests to these areas of the application