Is your software architecture what you think it is? The designs we communicate to each other aren't always what we expect when it comes to source code. Paul Duvall returns from his hiatus in this installment of Automation for the people to demonstrate how you can discover architectural deviations by writing tests using JUnit, JDepend, and Ant to discover problems proactively instead of long after the fact.
Of the many software development projects I've worked on and observed, one thing is almost a constant: The architecture you think you have is often different than what you actually have. Analyzing code metric reports, like those created by tools such as JDepend (see Resources), can be effective in determining if your code adheres to an established architecture. Some teams reverse-engineer their code into UML diagrams for the same effect, and others even use an IDE that generates these same artifacts while coding -- real-time reverse-engineering. Yet, all of these approaches are still reactive. You must manually review and analyze a report or diagram to determine an architectural violation, which in some cases could be long after the fact.

Refactoring is a well-accepted practice for improving existing code. Yet, how do you find the code that should be refactored, in a consistent and repeatable manner? This installment of Automation for the people explains how to use static analysis tools to identify code smells to refactor, with examples showing how to improve odiferous code

This article covers some of the various types of automated developer tests you can run with every source code change. It provides examples of Selenium, DbUnit, and JUnitPerf tests that can help you discover application problems early -- that is, if they're run often.

Java deployments are often messy, error-prone, and manual, leading to delays in making software available to users. In Part 1 of a two-part article in the Automation for the people series, automation expert Paul Duvall identifies a collection of key patterns for developing a reliable, repeatable, and consistent deployment process capable of generating one-click deployments for Java applications.

Java™ deployments are often messy, error-prone, and manual, leading to delays in making software available to users. In Part 2 of this two-part article, automation expert Paul Duvall expands on a collection of key patterns for developing a reliable, repeatable, and consistent deployment process capable of generating one-click deployments for Java applications.

Load testing is often relegated to late-cycle activities, but it doesn't need to be that way. In this installment of Automation for the people, expert Paul Duvall describes how you can discover and fix problems throughout the development cycle by creating a scheduled integration build that runs JMeter tests.

Managing source-code dependencies among projects and tools is often a burden, but it doesn't need to be. In this installment of Automation for the people, automation expert Paul Duvall describes how you can use the Apache Ant project's Ivy dependency manager to handle the myriad dependencies that every nontrivial Java™ project must manage.

Project documentation is often one of the necessary evils in delivering a software product. But imagine being able to generate your documentation at the click of a button. In this installment of Automation for the people , automation expert Paul Duvall explains how you can use open source tools to automate the generation of Unified Modeling Language (UML) diagrams, build figures, entity-relationship diagrams (ERDs), and even user documentation.

Automated builds aren't just for development teams — they can be extended to facilitate moving software from development all the way into production. This article describes how to use Ant with Java™ Secure Channel for remotely deploying software into multiple target environments.

The Java Persistence API (JPA), which is part of the Enterprise JavaBeans (EJB) 3.0 spec and is now the standard API for persistence and object/relational mapping for the Java EE platform, provides several advantages to Java developers for data-binding purposes. First, it provides a common API for persistence in both the standard and enterprise Java worlds. Second, the JPA provides a standard API that can be used for multiple different data stores. Third, JPA provides object-relational mapping technology that can be applied in the same manner to these various contexts (standard Java, enterprise Java, and various databases). This article provides an overview of how to fully enjoy these advantages of the Java Persistence API.