TestNG And What We'd Like Code To Be

I was browsing through reddit today and it looks like it's surfaced an old blog post from 2006 by Cedric Beust. Cedric was one of the founders of the TestNG project years ago, and as far as I know he still maintains it.  In the blog, he's critical of engineering practices associated with Agile, or rather, the way that they've been communicated through the industry.  I think he makes fair points about some of it. Agile people have been strident, but there's one point where I think he misses the mark.  He dings people in the Agile community for using toy examples when they explain TDD - for not really getting into the 15MLOC code bases that are "real serious stuff" and incredibly complex.  Well, I deal with plenty of those.  There are definitely ways to simplify, and start making it all tractable, but to really do that, you have to really want it.  You have to be willing to shoot aggressively for simplicity of implementation.

It's odd that the blog resurfaced now, because over the past few months I've been using an anonymized representation of TestNG's code along with some other projects to get a sense of what people think about code structure and what they prefer to work in.  To do this, I've taken class files from each project and produced graphs of the internal dependency structure of each of the classes.  Then I took the pictures and made them into little movies.  Below I have links to movies of TestNG and JUnit. People I've shown these to, with the names hidden, are pretty clear about the type of code they'd like to make changes in.

Here's the crib sheet for the diagrams:

• Hollow Ellipse - public method
• Shaded Ellipse - protected, private, or package private method
• Rectangle - field
• Line - a use-dependency from a method to a method or a field.

In both movies, you'll notice that there are some classes which consist of just hollow ellipses - there are no lines connecting them.  Those are interfaces.  You'll also see classes of various sizes and complexities.

Note that due to some quirk of fate, the more complicated classes tend to be toward the end of the movies. There's a dramatic arc to the universe, I guess.

There's a lot you can about code from looking at these diagrams, despite the fact that they subtract a lot of information.  Some frameworks are very interface-centric and others aren't.  At some root level, people do seem to have different senses of aesthetics when they write code.  Some people like lots of small simple classes and others think that having some very large classes is okay. The thing that interests me right now is whether aesthetics matters.  I think that we can make a good argument that it does, but we can also make an argument that, of course, context is king.. that there are reasons to make very big classes in projects.  I'm just not sure that I buy it. I think people do it because it's easier and either they don't realize that they can make it all simpler, they don't feel that they have the time to invest in it, or they feel it isn't worth the effort. And, sometimes, on the latter point they might be right.  Maybe not all code has to have that simple, small aesthetic.

I'm not going to come down on either side in this blog, but I will say that all other things being equal, I know what kind of code I'd rather work in.

Comments

[ิbestmore]

Are learning. It was accepted.

[Mika Moilanen]

Reading Cedric Beust's blog posting reminded me of interesting article by
B. Meyer title "Seven Principles of Testing" (http://www.eiffel.com/general/column/2008/02.html).

In my opinion it provides a solid and well-clarified background for discussions around the effectiveness of testing.

Discuss :)

[Akash Chopra]

I'm guessing that each "scene" in the movie is a different class within the system?

It would also be interesting to display multiple classes in a single scene and show how they evolve over time. This could help visualize the different between festering code bases and budding code bases.

How did you produce the dependency graphs? Do you have a tool that analyses the code?

[tobi]

People have different skills. I personally only start to refactor when the complexity has risen beyond my abilities. THat is whysome people need to go mad with patterns and some tend to have mire concrete implementations. The latter ones are written by people who can survive a little less separation than the others.

[ิbestmore]

I read, I rarely understand. But thank you this article. I'll read it and new

[SEO India]

after finding an ocean of companies, choose one according to your requirement and budget. So, what are you thinking of? Just make search and get results you could not have imagined.

http://www.seosoftwareservices.com
www.seosoftwareservices.com/seoservices.html
www.seosoftwareservices.com/web_development.html
www.seosoftwareservices.com/linkbuilding.html

[seetoo]

Having reading this blog i realize it was helpful in so many ways. Genius!