by on

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?

by on

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

by on

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