ClassMock is a framework that helps the creation of unit tests for components that use reflection or annotations. In this kind of classes, the behavior is dependent of the class structure. This way, each test case usually works with a different class created specifically for the test. With ClassMock is possible to define and generate classes in runtime, allowing a better test readability and logic sharing between tests.
For those of you who've got into it you'll know that test driven development is great. It gives you the confidence to change code safe in the knowledge that if something breaks you'll know about it. Except for those bits you don't know how to test. Until now XML has been one of them. Oh sure you can use "<stuff></stuff>".equals("<stuff></stuff>"); but is that really gonna work when some joker decides to output a <stuff/>? -- damned right it's not ;-)
Abbot helps you test your Java UI. It comprises Abbot, which lets you programmatically drive UI components, and Costello (built on Abbot) which allows you to easily launch, explore and control an application. The framework may be used with both scripts and compiled code.
There are a number of open-source unit testing tools available. So why another one?
Well, this one addresses a specific need - an easy way to test XML-based servers. If you have a server that communicates with clients via XML messages, you can end up putting a lot of effort into using one of the unit-testing frameworks to test all the messages. Just think of all the code needed to set up communications, construct messages, and verify responses.
A simple alternative is to document XML messages and expected responses, without having to write any code. Let XmlMessageTest send each XML message to the server, verify returned messages against expected results, and produce a simple report of test results.
XmlMessageTest is written in Java and should be able to run any Java-enabled platform. It's been tested on Windows XP and Linux. It can be easily integrated into your build process.
AtUnit minimizes boilerplate code in unit tests and guides test development by enforcing good practices.
* mark exactly one field with @Unit to indicate the object under test.
* mark fields with @Mock or @Stub to obtain mock objects
* inject your tests, and your test subjects, using your favorite IoC container
Mock Objects Integration
AtUnit integrates with JMock or EasyMock to provide mock objects:
* obtain a JMock context simply by declaring a field
* annotate fields with @Mock to obtain JMock or EasyMock mock objects
* annotate fields with @Stub to obtain a JMock or EasyMock stub object
... or you can use your own mock objects plug-in with two easy steps:
* implement the MockFramework interface
* annotate your tests with @MockFrameworkClass(MyMockFramework.class)
Container Integration
AtUnit integrates with Guice or Spring to take all of the work out of dependency-injected tests.
With Guice:
* never see the Injector, never write bootstrapping boilerplate!
* @Inject test class fields without even defining a Module
* declaratively obtain mock objects with @Inject @Mock
* if you need more binding flexibility, simply have your test class implement Module
With Spring:
* annotate fields with @Bean to get them from the Spring context
* fields annotated with @Bean which do not appear in your Spring context are added to it automatically! (This includes @Mock and @Stub fields.)
* AtUnit looks for a Spring XML file with the same name as your test, or you can specify the location yourself with @Context("filename")
* Most of the time, you don't even need a Spring XML file!
You can easily plug in other containers in two steps:
* implement the Container interface
* annotate your tests with @ContainerClass(MyContainer.class)
With so many Continuous Integration (CI) servers to choose from, it can be difficult to decide which one is right for you. In the second article of the series Automation for the people, development automation expert Paul Duvall looks at a handful of open source CI servers, including Continuum, CruiseControl, and Luntbuild, using a consistent evaluation criteria and illustrative examples.
Feedback is vital for the practice of Continuous Integration (CI) -- in fact, it's the life blood of a CI system. Rapid feedback enables speedy responses to build events that require attention. Without feedback mediums like e-mail or RSS, builds in a broken state have the tendency to stay broken, which defeats the purpose of CI in the first place! In this installment of Automation for the people, automation expert Paul Duvall examines various feedback mechanisms that you can incorporate into CI systems.
When starting new projects, most of us plan to review code before actually releasing it into production; however, when delivery schedules supersede other factors, reviews tend to be the first practice thrown out. What if you were able to perform a portion of these reviews automatically? In this first article of the new series Automation for the people, development automation expert Paul Duvall begins with a look at how automated inspectors like CheckStyle, JavaNCSS, and CPD enhance the development process and when you should use them.
Nice article on IBM deveWorks: Ready to step up to the plate and hit a home run with your developer testing activities? In this installment of Automation for the people, development automation expert Paul Duvall covers some of the various types of automated developer tests you can run with every source code change. Paul provides examples of Selenium, DbUnit, and JUnitPerf tests that can help you discover application problems early -- that is, if they're run often.
What if you were able to discover potential problems in your code prior to building it? Interestingly enough, there are Eclipse plugins for tools such as JDepend and CheckStyle that can help you discover problems before they are manifested in software. In this installment of Automation for the people, automation expert Paul Duvall provides examples of installing, configuring, and using these static analysis plugins in Eclipse so that you can prevent problems early in the development life cycle.
How much time do you spend maintaining project build scripts? Probably much more than you'd expect or would like to admit. It doesn't have to be such a painful experience. Development automation expert Paul Duvall uses this installment of Automation for the people to demonstrate how to improve a number of common build practices that prevent teams from creating consistent, repeatable, and maintainable builds.
Fitnesse for Eclipse Plugin
Add Fit and Fitnesse support to your Eclipse tooling environment!
The FitNesse for Eclipse Plugin enables developers to more easily use the FitNesse and Fit frameworks from within the Eclipse environment.
Canoo WebTest is a free open source tool for automated testing of web applications.
It calls web pages and verifies results, giving comprehensive reports on success and failure. The White Paper provides an overview of the features and the design rationale. Detailed information is provided in the Manual Overview as well as the Install and Troubleshooting guides.
This is the homepage of the Code Analysis Plugin (CAP).
CAP is a plugin for the eclipse platform and analysis the dependencies of your Java project. It opens a own perspective and displays the results in an clear way using different diagrams.
There are many Continuous Integration systems available. This page is an attempt to keep an unbiased comparison of as many as possible of them. The goals are:
* Make it easier to choose an appropriate CI tool for your project.
* "Healthy competition aid" for the people involved in the development of these various CI systems.
Two powerful tools for communicating requirements from your customers, and testing those requirements, are Fitnesse and Selenium. Fitnesse, a wiki encapsulating the Framework for Integration Tests (aka FIT), enables customers to write sentence-like tests which can be mapped to the underlying system. Selenium drives a browser without all of the fragile mouse coordinate testing you get from a lot of testing tools (ala WinRunner).
This library allows you to use JavaBeans-style property matching for arguments when using EasyMock. Property matching is based on commons-beanutils as documented in Standard JavaBeans.
Phantastic!
"EclEmma is a free Java code coverage tool for Eclipse, available under the Eclipse Public License. Internally it is based on the great EMMA Java code coverage tool, trying to adopt EMMA's philosophy for the Eclipse workbench:
* Fast develop/test cycle: Launches from within the workbench like JUnit test runs can directly be analyzed for code coverage.
* Rich coverage analysis: Coverage results are immediately summarized and highlighted in the Java source code editors.
* Non-invasive: EclEmma does not require modifying your projects or performing any other setup.
The Eclipse integration has its focus on supporting the individual developer in an highly interactive way.
The update site for EclEmma is http://update.eclemma.org/."