Java
Java Stuff!!

MBA Blog


Java Blog

Essays

GMAT Thoughts
MBA Application Stuff

Subscribe to "Java" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

 

 

Thursday, March 27, 2003
 

Testing private methods?

So how do people test private methods....my opinion is that you should test private methods at all. Adequate test coverage should cover these methods through testing of the public and protected methods that use the private methods. However....

I know some people that don't even use the keyword private at all....they claim that it makes it easier to test every method (they make the methods all protected and make sure that the tests for that class are in the same package)....

So how do you do it...if at all...???


8:08:52 PM    comment []

I just read Roy Miller's article on IBM developerWorks titled :Demystifying Extreme Programming: Winning with a pair and here are my problems with the article's key points. First of all the article states that the benefits of pair programming are below :

  • Reduces risk
  •  Roy states "In addition, code written by a pair is almost always better than code written by an individual. Two heads really are better than one, especially for design decisions that affect the entire system".  My argument is that it depends on the programmers skill and style. If you have an experienced programmer and a non-experienced programmer pairing than are two heads really better than one? I don't doubt that pair programming reduces risk, I doubt that it reduces risk any more than having good communication across a team of talented programmers. If you don't have talented programmers on your team, then you have other problems.....

  • Makes the team more productive
  • Again, I don't think that pair programming makes the team more productive. How do you measure productivity? Roy states, "When you feel like giving up, there's somebody else there to encourage you and keep you going. Teams are also less likely to neglect tests or other important details -- that alone increases productivity." Again, if you have a talented team of programmers who communicate well, the programmer having a problem will ask for help. There are code reviews to ensure that there is test coverage. Keep in mind....that when you have two programmers solving one problem, you could have two programmers solving two problems just as well. There is an oppurtunity cost involved that somehow disappears because Pair Programming advocates think that the code is better. Do two painters painting the same painting make the painting any better. I don't think that if I paired with Leonardo Da Vinci painting the Mona Lisa, it would have turned out any better....

  • Results in better code
  • Again....It all depends....Roy states, "Sometimes the simplest thing that could possibly work is hard until you get used to it. Pairing is a good example". I don't think Pair Programming is simple...nothing can be simpler than working on a problem and solving it by yourself....

    Now don't get me wrong most aspects of XP are great....but Pair Programming only works if you have two programmers who are similiar in experience and style....

    What are your thoughts...


    8:05:34 PM    comment []


    Click here to visit the Radio UserLand website. © Copyright 2004 Peter Ghali.
    Last update: 3/6/2004; 11:38:54 PM.
    This theme is based on the SoundWaves (blue) Manila theme.
    March 2003
    Sun Mon Tue Wed Thu Fri Sat
                1
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23 24 25 26 27 28 29
    30 31          
    Feb   Apr