Dapeng Li

Hungry, foolish and passionate – yet another software developer.

Archive for January, 2015

Traveling in Europe

one comment

From Dec 19 to 31 in 2014 I traveled in some of the countries in Western Europe. That was the first time I traveled there and the first time I traveled alone for that long.

My trip started in Paris, after spending 4 days there I went to Luxembourg, then Bruges. 2 days later I was in Amsterdam, then Berlin, and finally, Munich.

I enjoyed it a lot, I wanted to write something about the trip – thus this post you are reading now. I was writing about where I went exactly, what I enjoyed the most and the least, some tips I got from the travel, etc.

Then I realized those are not what I really got from the trip and what made it fantastic.

That thing is: traveling makes me curious.

Now I’m curious about why Parisians love and enjoy life so much; I’m curious about why marijuana and prostitution are not illegal in Netherlands and if that’s a good solution to the problems; I’m curious about the history of Berlin and its impact on its citizens, why Germany is so powerful in modern society even after losing two world wars; and many more.

I guess what I’m really curious about is life itself.

Curiosity leads to knowledge, knowledge leads to appreciation. Things that used to be irrelevant to me now become relevant, things used to just be names on the news and in the books now become concrete, colorful and attractive.

It feels good to get out of your room sometimes, and live in the world.

Written by Dapeng

January 10th, 2015 at 9:06 pm

Posted in Life

Tagged with ,

Things I learned from Kent Beck’s TDD screencasts

leave a comment

Recently I watched the screencasts by Kent Beck on Test-Driven Development (TDD).

Being glad to see I had been doing TDD similar to Kent, I learned quite something from the screencasts. Although my notes are just bullet points here and there, neither comprehensive nor introductory, I believe they can be of value to programmers and would like to share with you in this post.

Top-down or bottom-up

When adding tests and features, you can go with the top-down or bottom-up approaches.

  • Top-down: write code calling the non-existent method, create the method stub, implement and make the test pass.
  • Bottom-up: with some kind of implementation, extract part of it as a method and invoke that method. This is refactoring, build something then break it down into pieces.

Isolated tests

Tests should be isolated, means they should be able to run on their own, without affecting others. Kent puts clean-up code after the test methods.

Isolated here is not about dependency injection or faking, which is very important in TDD, but unfortunately Kent’s screencasts didn’t cover it.

Prediction game

Predict if the test will succeed or fail before running it, this way you are more engaged and not just programming by coincidence.

Finer grain tests as scaffolding

When it’s not green (there are failing tests) for a method, it’s OK to write finer grain tests to test the helper methods to be used by that method.

So at some point, you will have multiple tests failing, and you fix the finer grain tests first.

Those smaller tests can be considered scaffolding, if later you decide the helper methods should not be publicly accesible, it’s OK to delete those scaffolding tests.

“Yes” is an expense, “No” is a risk

Kent thinks carefully about whether to write the test for a method.

To quote (paraphrased from his summary in the screencast):

Every test is an expense, short and long term, it needs to pay back in Informational or Emotional Feedback; on the other hand, every test that you don’t write is a risk.

Interestingly, Kent plays a betting game with himself about that. I suggest you watch the screencasts and find it out.

Generalizing TDD

Kent generalizes the approach in TDD, the problem-development-cleanup cycle, to a larger context. He argues that this is not only the way we do TDD with a method (for a couple of minutes), but also how we implement some features (maybe for about 30 minutes, the length of one episode of his screencasts), how we solve a larger problem (for days, weeks, or longer).

I agree with him. Begin with the end in mind, seek short feedback loops, and review, that is how we solve problems. It seems so natural and simple, yet TDD – which applies this approach in a micro level – is so powerful however strange it seems when being first encountered.

Practice, practice, practice

Kent practices TDD on the same problem again and again. It goes like this: write some code, erase it, write in a different order, erase it, until it’s efficient and gives a lot of feedback.

This reminds me of the code kata and Chad Fowler’s book.

I would like to finish with a quote from Kent:

I’m not a great programmer; I’m just a good programmer with great habits.

Kent, thank you for the sharing and ispiration.

Written by Dapeng

January 3rd, 2015 at 6:46 pm

Posted in Programming

Tagged with