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?

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

If numbers come into play then quantification is implicit. Most of the projects I begin, I start estimating use cases in “High, Medium, Low” or “Small, Medium, Large”. Before the development starts we need to know how long something is going to take, hence we estimate. When we arrive at an estimate and put a schedule in place, subconsciously every one gets tuned to the numbers.

The numbers help in planning and helps the first release goes through; then the economical activities begin. Questions start arising like ‘Why two use cases estimated to be of the same size when one of them have fewer tasks?’ or ‘Why did two use cases with similar sizes take different times to complete?’. The completion of the use cases is what shows up as progress and slowly an illusion is created that the reduction in estimate is equal to the money saved. This leads to addition of scope similar to salami slicing.

The effect of salami slicing becomes visible over the course of time and developers begin to compensate by increasing the estimate. This vicious cycle leads to inflation and deflation of estimates, which in turn affects the project management’s ability to predict and plan. Quantitative/Objective measurement gives an illusion of control but will eventually affect the team’s ability to deliver value because there are lots of parameters which affects how something can be done; attaching a number to it will create those numbers to behave like currency. When we have something like a currency then we have economics.

Should estimation be very accurate?; No, it is like saying that with all the historic data and current conditions, we will be able to predict the outcome of cricket matches accurate to the number of runs scored. We should have estimates only as a guideline for planning and acknowledge that pin point accuracy will never be possible. Productivity is a result of so many factors and trying to assess that with a single number will result in expending time and energy away from productive tasks.

Image: jscreationzs / FreeDigitalPhotos.net