Unit Testing Struts 1.2 with StrutsTestCase, EasyMock and Aspects

We have a legacy application and a lot of presentation code is written using Struts 1.2.4. For unit tetsing the action classes we used the following approach.

StrutsTestCase provides both a Mock Object approach and a Cactus approach  to actually run the Struts ActionServlet, allowing you to test your Struts code with or without a running servlet engine. When you want to execute your tests as a part of the continuous integration environment in which all the unit tests should execute without deploying the application to the container.

For the following entry of Struts-config.xml

<action path="/login" type="com.dnbi.simpleaction.LoginAction" name="loginForm" input="/login/login.jsp" scope="request">
			<forward name="success" path="/action/simpleAction" />
			<forward name="failure" path="/failurePath" />
		</action>

and for the following action,

public class LoginAction extends Action {

	public ActionForward execute(ActionMapping mapping, ActionForm form,
			HttpServletRequest request, HttpServletResponse response) {

		ActionErrors errors = new ActionErrors();

		String username = ((LoginForm) form).getUsername();
		String password = ((LoginForm) form).getPassword();

		if ((!username.equals("vikas")) || (!password.equals("pass")))
			errors.add("password", new ActionError("error.password.mismatch"));

		if (!errors.isEmpty()) {
			saveErrors(request, errors);
			return new ActionForward(mapping.getInput());
		}

		HttpSession session = request.getSession();
		session.setAttribute("authentication", username);
		return mapping.findForward("success");

	}

the test would look like this

Non Functional Requirements: The Usual Suspects

In Part-I of this series we looked at what non-functional requirements were and how different people react to non-functional requirements.

Ask any team what do we mean by NFRs and most probable answer would be the following and most probably in the order mentioned below

• Performance
• Scalability
• Availability
• Security
• Maintainability
• Reliability

If you come up with a different list on your first pass when asked about NFRs, let me know.

The NFRs which would generally give the biggest bang for your buck are Performance, Scalability, Reliability and Availability. Once you have taken care of these I would recommend looking at the others like Security, maintainability, re-usability, usability etc.

So lets us look at them one by one

Non-Functional Requirements : The Art of Capturing, Analyzing, Developing and Validating

WikiPedia defines the NFRs as

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.

In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints“, “quality attributes”, “quality goals” and “quality of service requirements”. Qualities, that is, non-functional requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run time.
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.

Many people would turn their head in anguish on the mention of Non Functional Requirements primarily because of 2 reasons

How to Scale Your Web Application Without Looking Outside?

You create a web application. The application becomes popular and you start getting a lot of traffic. Traffic which you had not imagined. The drawback … the response time increases, the threads on your web servers start building up and the application starts to get on its knees.

Under these circumstances what most organizations would do is to start looking externally at promise the world tools like terracotta, memcache, in-memory data grid, etc etc.

Nothing wrong with that and probably you would need them anyway but before getting there it might be worthwhile to look internally to see if there is stuff which could be done with the application. This includes

Getting Ready for SaaS

With the current economic situation, more often than not, organizations would be evaluating various options available to get more for the buck. 2009 would be remembered as an year where almost everybody is keeping their fingers crossed and praying to finish the year unscathed.

Given the current scenario the SaaS model fits well with the plans of many organizations. It sits at a sweet spot between build versus buy and gives the desired economies of scale.

However, before getting onto the SaaS bandwagon there are an important set of questions that the organization needs to answer. The mindmap below tries to summarize them.

If Multi-Tasking is bad, Multi-Tasking with Multi-Reporting is Hell

There have been numerous studies to show that multi-tasking is not efficient and the human brain cannot multi-task efficiently. If we say that it is then we are deluding.

1. Multi-tasking is less efficient, due to the need to switch gears for each new task, and the switch back again. It involves a lot of context switching and thus less time to be effective.
2. Multi-tasking is more complicated, and thus more prone to stress and errors.
3. Multi-tasking can be crazy, and in this already chaotic world, we need to reign in the terror and find a little oasis of sanity and calm.

There are ways to be efficient and the rule # 1 is not to multi-task

So by now you would have agreed that multi-tasking is bad. Now let me introduce you to hell.

Automated Code Review is Not Enough

Code Review is considered to be the activity of verifying source code and rectifying mistakes in order to improve the quality of the code. Many times code review is associated with the painful process of painstakingly verifying code line by line and talk about a lot of mundane stuff. As a result of this many times code review becomes a mere eye wash when it is done manually.

Hence, came the tools like Checkstyle and PMD and many more both in the arena of open source and commercial softwares which helps the team write better code and check that automatically. Most of these tools have IDE integrations so that the code which is churned out is corrected at the source. Even if the developer wishes to check in code with checkstyle errors then there could be a gate just before the check-in process using pre-commit and post-commit handlers of version control systems like SVN and CVS.

{Sidenote – SVN allows atomic checkins hence this check can be easily applied there however CVS does not provide atomic check-in hence the pre-commit check is a little dangerous there.}

Anyway, back to main discussion

Automated code reviews can take care of mundane checks like code formatting etc. they can in general provide the following level of checks (from PMD)

• Possible bugs – empty try/catch/finally/switch statements
• Dead code – unused local variables, parameters and private methods
• Suboptimal code – wasteful String/StringBuffer usage
• Overcomplicated expressions – unnecessary if statements, for loops that could be while loops
• Duplicate code – copied/pasted code means copied/pasted bugs

So, in a nutshell the code reviewer would be absolved of the trouble of going through the above checks. However, if you notice then there are many things which would still need to be covered depending on the enterprise standards.

For example, one would have to manually check for details like

Continuous Integration in a Huge Multi-Module Project

The benefits of Continuous Integration cannot be discounted in any environment whether you are working on a small project or a huge one. The difference being in the set up and configuration of continuous integration in a multi-module project.

Multiple modules bring in additional complexity in terms of versions, teams collaborating, release cycles, separate sprints etc etc. In an ideal world all this would not be necessary and we would have just one module for the entire system. With every developer check-in the CI build would trigger. Of course the CI box would have unlimited processing power, load distributing capability and unlimited storage to still build the system of any size under 10 minutes.

The magic number of 10 minutes is an XP practice for CI where it is correctly stated that if a build is taking more than 10 minutes then the value of CI is lost. If the time is more developers would check in less frequently because who wants to wait for say 2 hours to get the status, they would rather check-in their code end of the day and even worse not wait for the build to complete. A broken build, which would happen many times would be fixed the next day. Now just assume that the team is distributed across time zones and are struggling with a broken build when they step into the office.

Let us switch the real world and agree that having a huge system build under 10 minutes is a far fetched dream. If you are working in a huge enterprise, where various complex systems are collaborating together then you would agree to my point.

So the best way to build a huge system is by distributing it into multiple smaller systems or modules and then building each module separately so that each module can build under 10 minutes.

Taking a simplistic view of the real world let us assume that we successfully divided our system into 3 modules.

System = Ʃ modules (A,B,C)

Better Software: Setting Up the Development Environment

This is first, in series of posts on how to write Better Software. The series would try to touch upon stories which would result in development of better software.

This post is about having a minimalistic development environment setup to do effective software development. As you can see in the picture we need 5 entities to begin with.