Related link: https://www.suite101.com/files/mysites/AskAlice/Clock.htm

My friend Marco emailed this link to “Nifty Javascript….”

https://www.suite101.com/files/mysites/AskAlice/Clock.htm

Trey Hutcheson wrote “I know the point of your post was not to discuss the merits of black-box vs white-box testing in depth, but could you take a moment to elaborate on your opinions ‘in general’ to the different approaches?”

Trey, I will start by referring to what’s said in Pragmatic Unit Testing - “Unit testing is done by programmers, for programmers.”

I have come across developers who reject unit testing as some thing for the QA team to do. Recently I ran into a few QA folks who wanted to know how they can write unit tests instead of their programmers. I can’t imagine the effectiveness of anyone but the programmer writing the unit tests.

Testing for functionality, behavior, correctness, performance, etc. is not optional and unit test does not replace those. Uncle Bob, et. al. say “Unit tests are necessary but insufficient as verification tools,” in Agile Software Development, Principles, Practices and patterns. However, as againts what’s
recommended in that book, I am not fully convinced that I would want (as a developer) to fully automate the acceptance testing. This is where, in my opinion, the QA folks may be better than me as a developer.

Generally speaking, I will have my QA team constantly test my product. I will hold weekly demo (or biweekly demo as the schedule may be) to get the user acceptance, input and feedback.

Unit tests, on the other hand are run more (much more) often. Each developer runs the unit tests on his/her own machine. Soon after the code is checked in, I run the tests on the build machine (using tools like cruise control). [Martin Fowler’s article on Continuous Integration is a must read.] I can’t imagine refactoring the code without these in place. [I strongly recommend looking at Mike Clark’s Pragmatic Project Automation.]

Further, what about testing the UI? Well, if most of the logic is moved away from the UI (and it should be) then running automated tests is not as important on these. You can run these tests on the behavior instead of visual of the UI. Then you can rely on the QA and business customers to validate the UI for its usability, etc.

To me unit testing is exciting since it is more of an act of design and aids with refactoring. Being a programmer (who loves it), I tend to focus more on the white box testing. Thank God, I have had opportunity to work with some good QA folks who take care of the rest :) These are some general thoughts.

What are your thoughts?

Related link: https://struts.apache.org

Now is a great time to be developing with Struts. With the recent release of version 1.2.4, now more than ever Struts provides a solid platform for developing complex Java web applications. While working on the upcoming Jakarta Struts Cookbook, I have come to appreciate a number of the innovative new features in Struts 1.2.

The move from Struts 1.0 to Struts 1.1 was a major shift. Struts 1.2 solidifies the Struts 1.1 platform and adds a number of additional features designed at empowering the Struts developer. Here are a couple of the features that I especially like in Struts 1.2.

Valid When

The Struts Validator introduced the ability to perform some types cross-field using the requiredif pluggable Validator. If you have ever used requiredif, you know what a pain it is. It is extremely verbose to code up the relationships in XML and, even then, you’re still limited in how you compare different fields to each other; basically indicating that one field must be supplied if another field is empty (or not). The validwhen validator makes these rules easier to code – you use a simple expression language – and even easier to code up specific validations (e.g. checking if two fields have the same value) that were not even possible with requiredif. One knock against the validwhen rule (which also applies to requiredif) is that it does not support client-side (i.e. JavaScript-based) validation. Personally, I prefer server-side validations for the control offered, so this is not a major issue.

Wildcard Mappings

Wildcard mappings allow you to define a generic set of mappings that can be used across all actions that follow a common workflow pattern and naming convention. On numerous occasions people have complained on the struts-user list that they have to write so many repetitive action mappings; that all essentially implement the same workflow. A typical workflow might be:

1. prepare the form for viewing
2. display the form on a JSP
3. submit the form to an action that saves the data
4. display a success page

Good developers will use common naming conventions that across-the-board so it’s easy for other developers to know what purpose the actions serve. Wildcard mappings allow you to codify the common pattern and naming convention. For example, here’s a set of action mappings that use wildcards:

<action
        path="/Edit*"
        type="com.oreilly.strutsckbk.ch07.Edit{1}Action"
        name="{1}Form"
        scope="request"
        validate="false">
    >forward
        name="success"
        path="/edit_{1}.jsp"/<
</action>
<action
        path="/Save*"
        type="com.oreilly.strutsckbk.ch07.Save{1}Action"
        name="{1}Form"
        scope="request"
        validate="true"
        input="edit_{1}.jsp">
    <forward
        name="success"
        path="/saved_{1}.jsp"/>
</action>

Now you when I have an action path like https://com.oreilly.struts/myapp/EditUser.do, the Struts RequestProcessor matches the wildcarded mapping to the URL; the {1} represents the text that matches the wildcard (*) (similar to a capture group in a regular expression). So you end up with the following “virtual” mapping:

<action
        path="/EditUser"
        type="com.oreilly.strutsckbk.ch07.EditUserAction"
        name="UserForm"
        scope="request"
        validate="false">
    >forward
        name="success"
        path="/edit_User.jsp"/<
</action>
<action
        path="/SaveUser"
        type="com.oreilly.strutsckbk.ch07.SaveUserAction"
        name="UserForm"
        scope="request"
        validate="true"
        input="edit_User.jsp">
    <forward
        name="success"
        path="/saved_User.jsp"/>
</action>

This is a powerful feature; promoting both reuse as well as naming standards across your application.

These are just a couple of new features that Struts 1.2 offers. Check the release notes as well as the Struts User’s Guide for more details. In general, I think you will find that you will want to use Struts 1.2 for new development. For existing Struts 1.1 applications, if you have to add new features to your application, then it might be a good time to go ahead upgrade to Struts 1.2.

Let me know of additional features in Struts 1.2 that you like (or don’t like, for that matter).

Related link: https://www.agiledeveloper.com/download.aspx

Where does your unit test go?

Test Driven Development and Test First Development have a number of benefits. It is more of an act of design than an act of verification as I have discussed in a three part series at https://www.agiledeveloper.com/articles/TDDPartI.pdf.

Where should the tests go? While writing test cases, you may have to access not only the public members, but also internal or package friendly members as well. In Java, you would want to write your test cases in the same package. In the case of .NET, you would put them in the same project. If you do not want to deploy the test cases, you can exclude them from your release build.

What if you need to test a private method or property of a class? First question to ask is, why would you want to test such methods or properties? Generally speaking, may be not. However, say I am writing an Order class and as part of its checkout method, I need to charge a credit card. The method to charge the credit card most likely is going to be private as it is an implementation and not something that the Order class would expose as public.

Why test it? You would certainly want to make sure you have handled the failure cases well. What if the card was invalid, or the charge did not go though or even you could not communicate with the service that authorized the credit card.

How do you test private methods in this case? Before I get into that, let me say that I am not suggesting that you write all your test cases like this. I would use this as an exception than a norm.

Why not write your test case that needs to test your private methods as an inner class in Java and nested class in .NET. Let’s try that.

Here is the .NET example:

	public class Order
	{
		private string Charge(Card theCard, double amount)
		{ //...
			return "chargeCode...";
		}
		[TestFixture]
		public class OrderChargeTest
		{
			private Order theOrder;
			private Card theCard;
			private double AMOUNT1 = 121.12;
			[SetUp]
			public void SetUp()
			{
				theOrder = new Order();
				theCard = new Card(...);
			}
			public void TestCharge()
			{
				theOrder.Charge(theCard, AMOUNT1);
			}
		}
	}

You can write more test to make sure the code behaves well for failure of the Charge.

Here is the Java code that does the same thing as above:

public class Order
{
    private String Charge(Card theCard, double amount)
    { //...
        return "chargeCode...";
    }
    public class OrderChargeTest extends TestCase
    {
        private Order theOrder;
        private Card theCard;
        private double AMOUNT1 = 121.12;
        public void setUp()
        {
            theOrder = new Order();
            theCard = new Card(...);
        }
        public void TestCharge()
        {
            theOrder.Charge(theCard, AMOUNT1);
        }
    }
}

In addition, I have a TestIt class as shown below:

public class TestIt
{
    public static void main(String[] args)
    {
        junit.swingui.TestRunner.run(Order.OrderChargeTest.class);
    }
}

When I run JUnit, I get the following error:

junit.framework.AssertionFailedError: Class Order$OrderChargeTest has no public constructor TestCase(String name) or TestCase()

The reason for this error is inner classes in Java are special. The constructor of the inner class is synthesized with a reference to the host class (the class in which it is contained). As a result, JUnit is complaining that it could not find a constructor which takes no arguments. Of the four types of inner classes (regular, local, anonymous and static) only the static inner class’ constructor is not synthesized with a reference to the host class. In Java, we should use static inner class instead of regular inner class here.

Modifying the code as

public class Order
{
    private String Charge(Card theCard, double amount)
    { //...
        return "chargeCode...";
    }
    public static class OrderChargeTest extends TestCase
    {
        private Order theOrder;
        private Card theCard;
        private double AMOUNT1 = 121.12;
        public void setUp()
        {
            theOrder = new Order();
            theCard = new Card(...);
        }
        public void TestCharge()
        {
            theOrder.Charge(theCard, AMOUNT1);
        }
    }
}

takes care of the problem.

On rare occasions, writing your test cases as nested classes in .NET or static inner classes in Java may come in handy. One down side is it is hard to exclude these from the release build. In the next version of .NET, with the introduction of partial classes, that should not be a problem.

What are your thoughts on TDD/TFC and where tests should go

Related link: https://www.washingtontimes.com/national/20041201-114750-6381r.htm

I can’t believe I’m linking to a Washington Times story (this wouldn’t be my paper of choice), but Former CIA Director George Tenet sounded off on the internet. Read the article, especially this excerpt:

The way the Internet was built might be part of the problem, he said. Its open architecture allows Web surfing, but that openness makes the system vulnerable, Mr. Tenet said.

Access to networks like the World Wide Web might need to be limited to those who can show they take security seriously, he said.

Mr. Tenet called for industry to lead the way by “establishing and enforcing” security standards. Products need to be delivered to government and private-sector customers “with a new level of security and risk management already built in.”

Well, the last paragraph is a nobrainer, sure, everything should be “secure by default”. Although, I have the feeling by “risk-management” he means, “Big Brother”-ish Digital Rights Management hardware. Those first two statements - I couldn’t disagree more. First, openness and transparency is the last thing this country has going for it. Second, the Internet has just started, and the WWW is nothing compared to what we’ll be doing in 20 years. Stifling innovation with government intervention at this point in the development of technology would be a huge mistake.

Start talking about regulating “who” can be “on the World Wide Web”? To me this is code for, “require all software publishers to be licensed by the federal government”. Say…..wouldn’t Microsoft love it if the Apache Software Foundation, or the Free Software Foundation had to work with some outrageous federal regulatory agency. Maybe we could name it something like, “Federal Information Security Office”. I’m thinking they would do something like making the lower levels of the TCP/IP stack classified and only hand out the specs to huge corporations with lobbyist. I can’t wait.

Also notice how Tenet boils the internet’s open architecture down to Web surfing. As if, “Web surfing” is the apex of this technology. Don’t let the dramatic changes we’ve all experienced during the past three decades fool you. All we’ve gained from telecommunications and computing is the ability to “surf” to the “Web”. The WWW may be the most visible benefit of the “Internet”, but the web alone didn’t do the trick. Without open access to the internet, the web would have been an overregulated, underused mess. No one has to ask the government to set up a web site. No one needs to talk to the authorities to publish a book, and no one needs to give a librarian a good reason why they want to read a Chemistry book.

I’ve got to say that the facts are in direct opposition to his remarks. Openness isn’t the problem. If anything is the problem, it is the danger posed to our security by proprietary software and closed standards. There is no public scrutiny for closed source software. If we reduce the transparency of our standards and software, we will reduce our security tenfold. Open source welcomes public scrutiny - “Find the bugs and we’ll fix them”.

Tenet is no stranger to being wrong. Or, has the Ministry of Truth started revising the past yet? Anyone read Orwell’s 1984 lately? That is a book we all need to read - again.

Lastly, Tenet misses the real danger - unresricted access to Gopher servers will destroy us. Gopher is like the Wild West. Being able to hyperlink to any other Gopher site in the world is our Achilles Heel.

Do you think “access to networks like the World Wide Web might need to be limited to those who can show they take security seriously”?

Related link: https://www.apache.org/~coar/mlists.html

Ken Coar (author of Apache Cookbook) assembled some mailing list statistics for every list hosted by the Apache Software Foundation.

One thing I noticed was that Jakarta’s commons-dev
is the second busiest mailing list at apache (second to tomcat-user). The health of a community has a lot to do with the activity (or more accurately the persistence of activity) on both a development and user mailing list. These stats are interesting because they show mailing list stats for healthy communities like the httpd project and commons-dev as well as stats for unhealthy communities like xindice.

From this page, you can see that commons-dev has 428 subscribers and averages 62 messages per day - cvs commits, bugzilla, jira, gump, and human messages. The commons-user list has 829 subscribers and averages around 12 messages a day. This is healthy, but it could be better.

On the other hand, the xindice-dev list has 284 subscribers (I am one of them), but only averages 0.63 messages per day. This means that of 284 people someone gets the itch to commit to cvs or send an email only once every two days. If you’ve been following xindice you will know that it is practically lifeless. But, the user mailing has almost twice the number of subscribers 492, and an even smaller average messages per day of 0.55. I brought this up once, only to have someone chide me for thinking that mailing list activity had anything to do with interest. But, the truth is, it does. If there isn’t a lively discussion on either the user or dev list, bugs are not being fixed and brainpower is not being spent on the project. That community is gone, and the people left are less than interested. Lot’s of people are watching xindice, but few are contributing.