Garry Pilkington

Do you test your private methods?

There is ample discussion on the blogosphere as to why you should or shouldn't test your private methods. 

In the 'NO camp'

http://www.redhillconsulting.com.au/blogs/simon/archives/000119.html, http://www.lostechies.com/blogs/chad_myers/archive/2008/11/21/do-not-test-private-methods.aspx

In the 'YES camp'

http://beust.com/weblog/archives/000303.html

I think there is some confusion as to why you should or shouldn’t.

Test-Driven Development

If you personally are practicing TDD then you are testing a whole chunk of code before and after refactoring. If your code passes the tests before refactoring, then you can be sure that any extracted methods are covered. That is to say you don’t need to test these methods (private or public) as their containing code have tests already.

Ok so you write your test, it fails. You then write your code to make the test pass. You are green. Then you refractor. After you refractor, you realize the method can be made private as nothing outside the class needs to know it is there. So now you have a private without any immediately related test (even though it is actually covered with the pre-refractored test).

Now if at some point in the future another developer comes along and adds a private method without any associated test; you now have two private methods, one with a test, one without. A quick glance at the source code of the test suite may not show that the first private method is covered. Perhaps forcing a rule that all methods should be tested should eliminate those non tested methods from creeping in. It may be a case of refactoring your tests to make sure each method has at least one associated test.

Regression testing

If you are working with legacy code and you are required to make changes to some public or even private methods, it would be wise to wrap tests around these methods, that way you can be sure they are functioning the same after the changes as they were before. This would be the same case for both public and private.

Code Coverage

Code coverage is the extent to which code has been tested; that is all code. So if you have 2 public methods and 98 private methods (just for example, this would be a ridiculously large class) and you have tests only for the public methods and not the private ones; do you have 100% code coverage? I wouldn't say so. I wouldn't be confident with a situation where I don't have any coverage of private methods.

I like the quote from  Cedric Beust post.

"if it can break, test it"

Why I prefer c# over VB

A couple of weeks back I was asked by a friend of a friend why I code in c# over VB. I didn’t give him a very good answer at the time as I just couldn’t pinpoint the reason. Since then I have had a real good think about it and have come to this conclusion. It just looks bulky. Not a good reason I know. I am not what you would consider a power developer, I use .net for relatively simple tasks and there isn’t any feature I would consider using one language over the other. So for me it just comes down to aesthetics. I can and have programmed in both classic VB and VB.Net and it was only about 4 years ago that I decided to have a look at c#. Now when I look at old code I have written in VB.Net I not only shudder at the overall crapness of my code, but also the amount of non-whitespace. A simple while loop in VB looks less clean than its cousin in c#.

   1: Dim counter As Integer = 0

   2: While counter < 20

   3:     counter += 1

   4: End While

   1: int counter = 0;

   2: while (counter < 20) 

   3:       {

   4:          counter++;

   5:       }

For me the second code example is easier to read, I know the while construct has ended by the placement of the closing brace I don’t need 8 superfluous characters to tell me that.

I was brought up with BASIC on the Commodore 64 and then Amiga BASIC through vb2,3,4,5 (didn’t really use vb6), then VB.Net and now c#. I do feel to a certain extent a bit of a traitor.

As has been reported elsewhere, word is that inside Microsoft they are trying to align the language development teams more so a particular feature that becomes available for one language will immediately be available in others. Will this blur the choice between languages?

Quickly reading technical articles and books

There is so much information out there pertaining to our jobs, a lot comes in the form of articles and books. How do you get through all this information fast without loosing comprehension?

Well this is my technique. I have used this since my university days, and although it works for me, it isn’t perfect for everyone. It is a mixture of speed reading and mind mapping. I use this for both technical articles such as research papers as well as chapters from technical books.

1. Quickly skim the paper or chapter noting down only the subheadings.
2. Use these subheadings as the main section of a mind map branching out from a central topic. This central topic could be paper or chapter title.
3. Look at and normally read the captions for any diagrams and charts (not source code though)
4. Speed read the article or chapter, don’t stop for words or phrases you don’t quite understand.
5. Speed read the article again, this time writing out any key points under their relevant topics on the mind map.
6. Go have a cup of coffee.
7. Look over your mind map. You will naturally be drawn to topic areas that interest you the most. If needed you could re-read these sections again.

There are several ideas behind this technique.

• Getting your brain to absorb only information that interests it. Most text from books and published papers are written in such a way that allows the reader to easily flow between the related subject matter within it.
• You look at images and charts before starting to read so as to give yourself a heads up for when you reach that section of the text.
• Not stopping for difficult phrases or words helps keep the rhythm up, you will be covering these words again at the second pass. Second time around you will have more of an idea of the context of the piece.
• The detail of the mind map automatically comes out from the subject matter that interests you. We all have a tendency to remember information that is of interest to us. This information can also give extra pointers for more research down different paths.

So the speed reading gets you through the text fast and the mind map emphasizes the important bits.

The main difficulty with speed reading I find is keeping it up. Initially it is so easy to drop back into normal ‘speaking in your head’ reading. Keep practicing, it will get easier.

What about code?

The only way I find to understand the code aspect of these articles is to just type it in and step through using the debugger. I find learning easier if I can do some practical work to go along with the theory. Does anybody else have any tips?