Unit tests | Backdoors

Every time I find it difficult to think of a good test to start, I am always tempted to try backdoors like getters, setters to help get started. The backdoors are not limited to getters and setters alone. Here is a list of my observations which has been used only for writing unit tests in Java easier.

  • Getters/Setters
  • Constructors
  • Equals implementation
  • Protected or package private access specifiers for variables and methods
  • ToString implementation
  • Special backdoor methods to alter the state of an object (The worst of all)

Any line of code which exists other than for another production code, it encourages a programmer in the future to exploit that backdoor for quick gains. As the tests are the specification to the production software, it is better to resist the tempation to use any of these. It also causes increase in code length and also an excuse for more people to follow the same path. The more time and effort I had spent trying to avoid backdoors, I have benefitted with more clarity in design. The benefits have prompted me to have routine static checks in the code base to keep them at check.

A question and a counter argument posed by a peer who belonged to another school of thought. If tests are considered to be first class consumers of production code, then is it right to have some backdoors help ease writing tests faster? Comments?

Who gets the credit?

It was the eve of a festival and I was returning back home from another city. The gateway to my home town was choking with unusually high traffic with everyone trying to rush to meet their near and dear ones. A stretch of few kilometers took more than an hour. It is at this time I witnessed a miracle. There was a sound of an ambulance siren approaching, on hearing almost every one on the road made their best effort to make way for the ambulance. In such a dense choking traffic there was a pathway made under a minute good enough for the ambulance to pass through. The patient who must have survived her illness might not even realized how tons of strangers on the road help save her life.

We humans are altruistic by nature and some how from inside it makes us feel good when we help others. Reader’s digest also mentioned in one article that may be only humans who were helpful to each other survived droughts, war and other adversities so that trait is deeply ingrained within us. There are also some beliefs about collective intelligence being superior than the sum of all individual intelligence. This is very evident from team games like football where the understanding between the team members a mix of skills gets the team to win. I have observed the striker scores more goals than anyone else in the team and most of the times ends up being the most valuable player. In my opinion the striker who scores a goal is largely enabled by the other 10 in the team.

Workplaces are no different, at many workplaces team work always matters; and many of those workplaces have awards like employee of the month/quarter/year or super star awards. The awards definitely help a lot to life the spirits of those who win it but it also puts a dent in the rest of the team’s spirit as the winner is enabled by the team and hardly there is a credit to the team. It is better to do away with these kind of awards and much energy can be concentrated on removing negative influence in the team like someone who exploits the system and team setup. It takes only one selfish person to bring down the morale of a high performing team, we must make sure our workplace does not offer any dividends to someone who tries to exploit; instead make the workplace such a way that the more cohesive the team becomes the more rewarding and enjoyable it is to work.

Image: Salvatore Vuono / FreeDigitalPhotos.net

Alternative to site to site VPN

Many of the corporates have their own IT infrastructure and take care of long term maintenance of their IT software and hardware. When technical partners/vendors help them develop new applications, the entire development and testing environments are provided by the clients themselves. As access to these will be restricted, developers will need to be on the VPN always. Site to site VPN helps the entire development team be on the VPN. If every developer has to be on VPN then there is a pain of logging in individually, worry about traffic every time they browse or sometimes making their system  not accessible in the local network.

Our development team had many machines with Mac and Ubuntu OS where we had trouble configuring the specific VPN software to work. We were also short of time to get the paperwork going and get a site to site VPN up and running. It was only with the help of few windows systems we were able to connect and run some tests and do development work. There was an urgent need for everyone to access client’s systems and resources, it was at this time Apache HTTP server and Rinetd came to the rescue.

This is what we did to solve our VPN bottleneck.

  1. Get a machine such that the VPN software runs on that OS. In our case it was windows XP.
  2. Give the machine an easy to remember name on the network like my-team-vpn.company-domain.com
  3. Install Apache HTTP server and set up ProxyPass and ReverseProxyPass such that all the HTTP based test environments are given a local url. Like http://my-team-vpn/QA-env/index.html should serve from http://client-machine-QA-env/index.html
  4. For other TCP connections like DB and LDAP, setup Rinetd and configure redirects like 10.1.1.1 369 to IP and port on the client machine.
  5. Keep the machine always on the VPN.
  6. Publish the URLs and ports to be used by the development team without using VPN.

With the above steps we were able to complete our development without going through the paper work of setting up site to site VPN.

Image: jscreationzs / FreeDigitalPhotos.net

Scale

Humans over time have acquired the skill to use a linear scale. Radio Labs aired a talk which explained about experiments done with children and some tribes who have not been exposed to linear numbers. The experiments suggest that we are conditioned to use numbers in non linear scales. It is easy to express differences in ratios than linear count between them. The experiments have also been replicated on animals and found that they also understand differences in ratios than the count in between.

We are accustomed to say that the difference between 1 & 2, 11 & 12, 1001 & 1002 are all same.  When we project these numbers side by side as countable items like trees or birds in a picture; every one will immediately spot the difference between 1 & 2, most will spot the difference between 11 & 12 given some time to count and people will struggle to find the difference between 1001 & 1002 unless the images are arranged in neat grid with enough time given to count. The results of an experiment with Amazonian tribe who had not much formal education is here. In short, it illustrates that people will be inclined to choose their scale to be logarithmic instead of linear one. Musical scales are non linear where the frequency doubles every octave. Like music even the colour frequencies of VIGBYOR is non linear.

We deal with numbers day to day and most of the working force have spent significant amount time in school playing around with numbers which were in linear scale. Deep inside us we still carry what we inherited from our ancestors and are well suited to deal with ratios. May be that is why our ancestors designed the musical scale to be non linear. “The Da vinci code” novel also talks about golden ratio which is observed every where in nature and that is non linear.

In software development I have observed this is true when it comes to estimations. Instead of mapping estimates to days of effort it is more easy to represent it in Fibonacci series (the ratio is 1.6 or golden ratio in fibonacci) or Log base 2. Trying to fit in a linear scale has created more misunderstandings between team members as each one had a different picture on where to place an estimate on a linear scale. I have observed dissonances in estimates from people even when using logarithmic or fibonacci, that dissonance will increase manifold if we use a linear scale. If we try to deal with numbers in ratios in day to day life then may be we can get lots of advantage by using our hard wiring inside.

Image: FreeDigitalPhotos.net