WatiN

Inspired by Watir development of WatiN started in December 2005 to make a similar kind of Web Application Testing possible for the .Net languages. Since then WatiN has grown into an easy to use, feature rich and stable framework. WatiN is developed in C# and aims to bring you an easy way to automate tests with Internet Explorer. Following is the Hello world example of web testing automation; searching Google with WatiN.

I'm currently in the middle of refactoring all of my test code.  I've decided to split my test folder into two subfolders, unit and integration.

\src\test\java\integration
\src\test\java\unit

I have a lot of long running integration tests that need to be separated from my unit tests.  My were getting slow and difficult to manage, so hopefully JUnit will be able to fly through my newly organized unit tests.

I haven't had the "pleasure" of fixing a Windows install for a while, but tonight I was helping a friend fix their PC.  Apparently Winsock2 got corrupted on their system somehow, I suspect some web browsing spyware... Services that I've never seen fail were failing, things like DHCP and NETLOGON.  I installed the XP support tools from the XP SP2 CD and ran netdiag /test:winsock.  That of course produced a nice fat error, which prompted me to run netsh winsock reset.  After doing so the system started behaving much better and I was even able to get on the internet and login to the system without crashing.

MS KB Article that helped me 811259

Apparently the latest log4j alpha release does not contain the new message pattern implementation that I talked about in my previous post.  Currently I'm working on a Logger wrapper that adds this functionality for the time being.

I've been using log4j and log4net as my logging facility for some time now, and haven't thought a lot about it.  I did today though...  I had a junit test with some mock objects that were getting used only if debug logging was enabled.  Do I know the developer running the test has debug logging enabled?  The answer is, the unit test shouldn't care, but how do I get around this in my unit test?

The real issue I was having was that in my class under test I was doing things like log.isDebugEnabled() to avoid a bunch of string concatentation in my logging.  Apparenlty there's a better way to avoid the string concatentation penality and also provides cleaner syntax IMO.

As of log4j version 1.3, there exists a significantly more convenient alternative based on message patterns. Assuming entry is an object, you can write:

l.debug("The new entry is {}.", entry);

After evaluting whether to log or not, and only if the decision is positive, will the logger instace format the message and replace the '{}' pair with the string value of entry. In other words, the paramerized form does not incur the cost of parameter construction in case the log statement is disabled.

Thus, the following two lines will yield the exact same output. However, the second form will perform at least 30 (thirty) times faster in case of a disabled logging statement.

l.debug("The new entry is "+entry+".");
l.debug("The new entry is {}.", entry);

A two argument variant is also availalble. For example, you can write:

l.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

I finally found out there's a name to a design pattern I've used previously.  The open closed principle: a class should be open for extension, but closed for modification. 

A co-worker was working a fairly complex presenter class that was originally difficult to test, had way to many responsibilities, and would need to be modified each time a new area of the application was completed.  After extensive refactoring it now is testable and passes the open closed principle.  Basically the presenter class was broken down into 6 other classes which implemented a strategy pattern.  Much more maintainable and easier to understand!

A Hibernate session is a "unit of work."  Useful resource for understanding unit of work and transactions within Hibernate: http://www.hibernate.org/42.html

Checked exceptions in Java suck.  The more I use Java, the more respect I have for Anders Hejlsberg.

http://www-128.ibm.com/developerworks/java/library/j-jtp05254.html

"Bruce Eckel, author of Thinking in Java (see Resources), says that after years of using the Java language, he has come to the conclusion that checked exceptions were a mistake -- an experiment that should be declared a failure. Eckel advocates making all exceptions unchecked, and offers the class in Listing 2 as a means for turning checked exceptions into unchecked ones while preserving the ability to catch specific types of exceptions as they are propagated up the stack (see his article in the Resources section for an explanation of how it can be used)."

See comments...

/**
* Iterates through all mapped Hibernate classes and attempts to select
* all for that table/class pair. If this test does not fail then this
* indicates that the hibernate mappings at the very minimum match the
* database schema.
*/
@Test
public void allHibernateMappingsWork()
{
    Configuration configuration = new Configuration();
    configuration.setProperty(Environment.SHOW_SQL, "true");
    
    SessionFactory sessionFactory = configuration.configure().buildSessionFactory();
    Session session = sessionFactory.openSession();
    
    Map metaData = sessionFactory.getAllClassMetadata();
    for (Iterator i = metaData.values().iterator(); i.hasNext();)
    {
        EntityPersister persister = (EntityPersister) i.next();
        String className = persister.getClassMetadata().getEntityName();
        String qry = "from " + className + " c";
        List result = session.createQuery(qry).list();
        assertTrue("No results for " + className, result.size() > 0);
    }
    
    session.close();
}

To turn on the touch screen feature of an emulator, go into C:\WTK25\wtklib\devices\[device]\ and open up the [device].properties file.  Set: touch_screen=true.

JXPath looks pretty useful.  It provides XPath syntax to query your POJOs - very similar to LINQ.