debuggable

Hey folks,

the last week I have been dealing with an implementation of code coverage analysis for the upcoming release 1.2 of CakePHP. For those of you who do not yet know what code coverage is, here is a short excerpt from Wikipedia:

Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing.

There are several different kinds of criteria to code coverage. The two most important ones are line coverage (or statement coverage as wikipedia puts) it and path coverage. Line coverage basically analyzes if each line of the subject-under-test has been executed during the test.

Path coverage examines if every possible route through the code has been executed. Since I rely on Xdebug for the implementation we are talking line coverage here.

So how is it going to work? Pretty simple actually. Whenever you run a CakePHP test case Cake assembles information in the background about which lines of your subject-under-test are called. Then it will display all code lines from the subject-under-test and mark those that were "covered" (ie executed by the testcase) and which were not. Lines that play no role for the code coverage percentage, such as multiline comments, will be displayed in a different color.

How could an example report look like? Here you go:

I have also implemented a diff-style report. It just lists all the lines that are not covered by your tests and then seven lines before and after each of those. This is what the diff view looks like for the cakephp core router.test.php:

Within the dev team we are currently discussing these two views. If you favor one of these, can recommend another or just want to voice your opinion on the looks of them, please do so by commenting. For your information: Code coverage analysis currently only works for separate test cases only. However, the plan for this week is to get aggregate code coverage working. This means that your group tests are analyzed and the coverage percentage displayed for each of the test subjects involved.

If you ask me this is a very valuable tool when developing tests for your cakephp application. Although we are talking line coverage here and not path coverage (do your tests go through every possible paths through your application?) it is a good indicator of how thorough your tests are.

Please fire away your suggestions!

-- Tim Koschuetzki aka DarkAngelBGE

Hey folks,

this is an experimental post on the psychology of programming. As of lately I have become very interested in the thought processes that cause us to write certain code. Because I believe understanding the patterns in your own thinking will by far make the biggest impact on how good you will get as a programmer. Forget design patterns, forget unit testing, forget all those functions you know. Important is to question why they exist and how they could be improved. I'm not saying you cannot be a good programmer if you do not care about this. But I am saying you will most likely never exceed the skills of all the other programmers out there. You will more or less write the same code everybody else does.

In the scope of this post I will try to explain a very simple thought pattern that I am calling "return home early" that evolved out of me analyzing my coding habits. The simplest way for you to follow the thought process is to have a look at the following bad code:

What you see is a typical Post::edit action like the one used on this blog (in fact I derived it from it). I tried to cripple the code so badly that you can tell what is wrong with it right away:

There are way too many levels of nesting for something that should be dead simple.

But yet, most projects that I have been involved with had code like this in them. This is not because most programmers are stupid, I think this is a result of logic thinking. Even so I luckily never had to draw much flow charts in my life, I think that my brain somewhat works like one. I think most of us who think logically develop their thoughts in form of a tree, jumping from node to node, leaving dead ends all over because we are not able to focus on too many things at once. This is also why mind mapping is a useful technique that I started to embrace lately. It helps us to increase the amount of connections per node in our thinking and lets us discover new nodes (ideas) previously unreachable with our normal thinking.

Another technique that really helps understanding your thinking is to visualize it. Close your eyes and try to see the patterns in whatever it is you are doing (not just programming) for a second. Applied to our particular example above, we could visualize the code above like this:

Now suddenly it becomes very easy to simplify what we are doing. All we have to do is to align those nodes that are not dead ends. Visually speaking that means to make a re-arrangement like this:

In terms of code this means to get rid of anything that looks like an else statement and use a return statement wherever we hit a dead-end (return home early). Our particular example for example could be re-written as follows:

What you can see right away is that we have saved a couple lines of code, but that's not even the exciting part. The exciting part is that by recognizing a pattern in our thinking we were able to produce much simpler results! An interesting implication of this technique is that it is much harder for us to reverse engineer our logic than it is for us to produce it. This is why reading other people's source code can be difficult at times. It is not that their code is difficult, it is just that it's laid out in the way of the thought process that created it. So when you sometimes read a piece of code and really enjoy reading it, it is most likely a sign of conscious thinking and reorganization of typical thought patterns into human readable patterns.

Note: I do not use the word refactoring in this post because the word has too much association with design patterns for my taste. Design patterns itself do not make things simpler! The process of reorganizing your natural thinking does.

Regarding the second code example: I cheated a little bit in terms of saving if statements by using my Assert class to simplify things even further.

All right, I'm really interested in hearing if some of you would enjoy more posts like this. I also still have tons of behaviors and components in my backlog for publishing, but this is a fascinating topic to me right now that I would like to write more about.

-- Felix Geisendörfer aka the_undefined

Hey folks,

this is just a quick announcement that the migration has been completed and less stuff seems to be broken than we expected : )!

So you can go ahead and leave some feedback on the new Design, Navigation and most importantly all the bugs you notice while using the site. We worked incredibly hard, for the past 7 hours we've been coding non stop and did ~70 commits to the SVN repository for this project.

But still there is some work left to do. While all blog posts links should have survived the migration many others pointing to our categories and sub pages have not. We also want to make the syntax highlighting for code prettier (it's supposed to look like our Textmate theme, but Geshi isn't fine grained enough) and finish all the project pages listed on the right side.

One good news however is left: We have re-categorized all our posts (See the "Read more about section to your right") and also marked about ~60% of all posts as deprecated. That means they won't show up in any index or search on our site, and if you find them via Google a big warning will be displayed saying the content is not up to date anymore. This way we hope people will start browsing through our archives and read some of our previous posts while we work on new material over the next couple of days : ).

All right, thanks for all the feedback in advance!
-- Felix Geisendörfer aka the_undefined

Hey folks,

wednesday will be the official funeral for thinkingphp.org and php-coding-practices.com. Both blogs will be shut down and hopefully come back phoenix style as debuggable.com right away ...

However. There still is lots of work left on the the new blog system and Tim and I are already swamped with client work, commitments to open source projects and various other things.

That means chances are this is going to be a funeral indeed and things might go horribly wrong in the process of transition. So please get ready to send all your complaints about broken links, features, pages, etc. to bugs@debuggable.com.

We've decided to set this little deadline (no pun intended) for ourselves since launching the new blog has been one of the things we've said is about a week or two from happening for the past couple months and nothing has happened. This is especially frustrating since we currently consider this to be our most important long term project and several other small projects and software releases have been pushed back because of it.

So mark your calendars and hope the best for our two sites when we pull the plugs on April 23rd. We'll do it regardless of how much progress is going to be made in between now and then ; ).

-- Felix Geisendörfer aka the_undefined

PS: Sorry Wordpress, you have been good to us for all those years - but its just time to move on ...

Hey folks,

just a quick question to all of you: What is the best written programming book you know? I don't care what language or technology it is about. I'm looking for a book on the topic of programming that has the atmosphere of a good novel and really sucks you into it. A book you take with you everywhere b/c you want to know how it continues ; ).

The thing is that most programming books that I know are not like this. They usually tend to either be way to simple and stupid throughout the entire book. Or way too intimidating and difficult so that you need to re-read every page from the first chapter to get it. Or some of them just loose their bite after 150-200 pages and you find yourself skipping lots of pages.

So if you have any suggestions on *must-read* programming books please let me know. An exception would be books that are written about programming and team work itself and don't really contain code examples.

thanks a lot,
-- Felix Geisendörfer aka the_undefined