Spring Certification Study Guide / Notes, Resources and Mock Exams

3 07 2010

I am currently working on my Spring Core Certification (via the Grandfather stream). As part of my studies, I have created a set of study notes which I want to share with the community.

The notes can be found at http://springcert.sourceforge.net

These notes are very closely based on the Spring Reference Document (2.5.6). I have tried to summarize the “important parts” of the reference documentation, while excluding the parts that I do not think will be in the exam. This is just my “best guess” based on comments in forums, mock exams and official Spring resources.

I have linked each section back to the Spring Reference Document (so you can easily refer back to the original documentation)

I have also included links back to the Certification Objectives and tried to highlight key concepts and likely exam questions.

As my studies progress and my Spring knowledge increases, I will update these notes.

Your feedback would be greatly appreciated. Please register suggestions, defects and improvements for these notes via Spring Certification Discussions.

Enjoy and good luck with your certification!!
Cheers
Gavin

Advertisements




Top Unit Test Tools

1 02 2010

One of the main benefits of the Agile methodologies (XP, Scrum, etc) is the growing popularity of unit testing. This used to be a dark art practiced by the most geeky of geeks. Only a very brave developer would spend time implementing a unit test instead of rushing a shiny new feature out the door. However, software developers (and their managers) have seen the light (or are, at least,  a little more open to trying out this practice on real projects).

I have been “unit testing” for the last 8 years. Recently I decided to give my unit testing toolkit an update and check out what new shiny toys are available. Here is a summary of what I found / experimented with…

  • Jmockit. This is the best mocking framework I can find. It is magical. With JDK 1.6, you add the jar to the class-path and you can instatnly mock anything. Yes, anything. I tried mocking static methods, final methods, private methods, objects created with the new operator. There is nothing this baby can not do!! Check out the comparison matrix.
  • Jmockit code coverage. Not only can this tool mock with the best of them, it can do code coverage as well. Seeing the tested paths really helps you in building efficient and comprehensive tests. It even tracks how many of the possible execution paths are covered. Put that in your pipe and smoke it!!
  • DBunit. This old tool has been brought back to life by a new team of developer. It is the best way to set-up a database before running your test. Mocks can get you a long way, but sometimes you just need to test with a real (big) database!!
  • Fest assert. OK, so I am a sucker for cool open source jars. This library makes your asserts much more readable.
  • TestNG. While JUnit 3.8 stagnated the Java unit testing world, TestNG rocketed ahead with features like annotations, parametrized tests, threaded tests, etc. JUnit 4 closed the gap a little, but TestNG is still ahead. Take it out for a spin and ditch that JUnit clunker.
  • Selenium. I am just getting my head around this tool. So far it seems the best way to test web sites. I have tried many other “web testing tools” and they all suck eggs big time. This one seems to have legs, but make sure you ditch the x-path locators (use css ones instead) and html format (use TestNG instead)

With so many great tools, there is no excuse for not developing (and maintaining) a comprehensive set of unit tests for your project!!





Technology trends…

15 04 2009

Which technology should you invest time and energy learning?

Web Frameworks

Javascript Libraries

Web Servers

Backend Technologies

Database





How about a game of ping pong?

30 03 2009

How about a game of ping pong?

Out of all the XP tenants, Pair programming gets the most attention.

However, IMHO, I do not think Pair Programming works very well.

I have been using the Extreme Programming methodology (or Agile methodology for the conservative or Politically Correct managers out there) for about 8 years. I have seen many advantages with some of the tenants … but Pair Programming has always been a disaster.

I tried it several times with different pairs and it always resulted in:

  • Significantly longer development times
  • No real increase in code quality
  • Keyboard / mouse hogging (the most assertive developer ends up driving)
  • Frustration

See here for scientific findings on Pair Programming.

While working on some code the other day, I had an idea of how to improve pair programming. I like to call this approach Ping Pong Development (P2D).

The basic idea is that each feature is developed by 2 or more people. Note… DEVELOPED … not PROGRAMMED.

For example,

  • Two developers work on a new feature.
  • The first developer starts the work and completes a basic implementation
  • The second developer reworks implementation (and tightens things up).
  • The first developer then extends the feature to cover new use-cases.
  • The second developer writes additional unit tests.
  • The first developer presents the implementation to the team.
  • The second developer fixes issues raised during the testing phase.
  • The first developer carries out the performance tuning.

Each developer works independently (so there is no keyboard hogging and no increase in effort). However, each developer knows that his work needs to be understood and extended in the very near future to complete the feature. The work is sent back and forth between the developers (just like a ping pong ball) until the feature is complete.

The advantages are:

  • It puts positive pressure on each developer to produce high quality code (easy to understand, conforming to code standards, well documented, hack free).
  • Knowledge of every feature is spread amongst at least 2 people. There are always multiple sets of eyes to pick up problems.
  • Issues would tend to be bigger and of higher value than the small programming ones picked up by Pair Programming.
  • Issues would be picked up very early. For big systems, code can sit around for years before someone needs to understand it / change it / extend it. Using P2D, the code is looked at and improved hours after it was written.
  • Both developers need to have an excellent understanding of the feature. For many code reviews, the reviewer does not really understand the code. They end up finding superficial issues. With P2D, both developers need to have an excellent understand the code and the requirements to complete the feature. No extra code reviews are needed!!
  • It is not revolutionary, so it is easier to sell / implement. There is no reorganization of desks, doubling of estimates, added resource planning complexity, etc. From the management point of view, it is business as usual … except they get a higher quality, better understood code base implemented by a more cohesive team.

First there was Programming (P), then Pair Programming (P2), then Ping Pong Programming (P3) and now Ping Pong Development (P2D)…

Hopefully, I will get a chance to try this idea out. Let me know what you think of it.