I went to the OSUG meeting tonight. The topics were Assimilator, a distributed computing toolkit, and agile development tools (focusing on Java and the JVM).
Assimilator
The creator and primary author, Kevin Hartig presented the Assimilator project. It’s basically a framework to run Java (or stuff on the JVM) on a cloud network. You put “services” in net containers and the net containers know how many resources are available, what type of processors they have, memory, etc. There is also the ability for a process to “split” and cluster if the interface to the software knows how to do that correctly (This is built in to the container for the Tomcat web server.)
It seemed very useful for creating parallel computing clouds or super redundant systems. Of course, it doesn’t offer a easy solution to the classic parallel stuff, you have to use algorithms that parallelize easily. It would be interesting to take some of the concepts (widely distributed, no single point of failure) and try to apply it to storage…That would make a good thesis project for someone interested 
Tools for Agile Development
We covered a ton of different tools and concepts related to agile development.
What is Agile Development?
Goal: Write relevant and working software
Relevant to customer requirements (longer, day by day feedback cycles, demonstrations, acceptance and functional tests, manual testing and use of software)
Working, functional code (very small, minute by minute feedback cycles with unit tests, typechecking, compiling, etc.)
One of the biggest difficulties in software engineering is making software that is relevant to the customer. A lot of the feedback for the “working” part can be automated and made very tight-cycle. On the other hand, to make the feedback from customers tighter, you need to demo and exercise the software constantly.
Rhythm is really important to Agile. Rhythm is not doing tasks in big clumps, but a little bit at a time at a steady pace. This is true at the low-level of incrementally developing and testing code, to the macro level of quick iterations and rapid deployment.
Tip: Posting numbers (Coverage, code analysis metrics) publicly allows clear communication, motivation.
The other problem is if you only concentrate on meeting customer demands, code tends to suffer and backslide with functionality regressions. This is where automated unit tests come in. They keep you from backsliding even as you alter code.
Automate as much as you can
Testing For Developers
It’s better to have a limited number of tools that are run constantly through continuous integration than a bunch of tools you run once a month. It’s easy to fix metrics, code violations, etc. if it only changes a little bit at a time. This means if you are adding automated tools to an existing project, first start by making sure that the metrics don’t get any worse. You can then make the metrics stricter slowly over the iterations.
For example, let’s say you have a project that only has 15% test coverage. Start off by setting Cobertura to fail if test coverage falls below that point. Then over a period of several iterations, increase the amount of coverage and the Cobertura water mark.
There are three broad categories of unit tests:
- Positive tests - these test that your code does what is expected when correct input is provided
- Negative test - these test that your code does not do unexpected things. E.g. not raising an error during normal operation.
- Exception Tests - these test that your code handles exceptional conditions correctly, e.g. throws correct exceptions.
You can also automate other types of testing, like performance testing. JUnitPerf and TestNG can do this. These tools also also support concurrency testing.
Mock Objects
Mock objects allow you to test dependent objects. They also allow you to easily test error conditions, for example, when a network connection goes down. Venkat recommended MockRunner is a framework to mock out containers for e.g. TomCat server stuff.
Tests for product owner/customers
easyb is a behavior driven-development (BDD) framework using Groovy for Java. It’s straightforward enough that customers can write at least the skeleton, and if you are careful with your interfaces, can write the tests, as well.
An example:
scenario “accounting” {
given “a new user”
when “the user creates a new account”
then “the user should receive a confirmation email”
}
Creates a new scenario. A report is automatically generated based on the string literals, and if this test is run all of the tests are marked “pending” since they only have documentation. Groovy objects can then be used in closures attached to each of the statements. shouldBe methods are automatically added to all objects and the ensure function can test other conditions. It’s really quite slick.
Code Analysis
Cohesion and Coupling
Rigidity can be measured by determining how many classes depend on a specific class. The more dependents a class has, the more rigid it is.
Stability can be determined by measuring how abstract the class is. The more abstract a class is, the less likely it is to change.
Ideally you don’t want your classes too rigid or too unstable.
JDepend can measure these two characteristics automatically and quantitatively. You can even set up a unit test to run JDepend and fail if the rigidity is too high. A distance of 0.2 or 0.3 is a good maximum for JDepend from the “Main Sequence”.
The important thing with all these automated metrics is to do them consistently. You’ll get discouraged if you only do it at the end of the iteration and will end up not using them at all.
Static Analysis
FindBugs and JLint, JLint can do dataflow analysis. PMD for copy detection.
Code Coverage
Go for 100% combined test coverage when using:
- Unit Tests
- Integration Tests
- System Tests
- Manual Testing
Tools like cobertura can measure coverage when deployed, as well. This means you can get coverage results for manual testing!
Jester mutation testing — make sure tests are actually testing functionality. This is the slickest thing since sliced bread and I’m going to get it to work with TestNG.
