A few days ago we changed nexus integration tests to use an embedded version of nexus instead of using a forked VM. Before every test Nexus is started and then stopped again after the test completes. This is done once for each test class (Junit: @BeforeClass=start nexus, @AfterClass=stop nexus).
During the first run we noticed some problems.Each time Nexus started, VM would use an additional 45Mb of memory. Soon we realized that our embedder was not working right. Stopping Nexus was not removing it from memory.
Setting all fields to null after stopping helped somewhat. But now instead of 45Mb of leak we were getting 40Mb, which was still too much when we had more then 200 tests to run. It was time to profile our tests.
At Sonatype we use yourkit for profiling, so I will demonstrate how to use yourkit to profile tests executed by maven. You should be able to use the same principle with any other profile tool.
Everyone knows Maven is great for running unit tests, and it is usually one of the first things that people learn when they are adopting Maven as a technology. Integration tests are another matter, and require a more detailed introduction. In this series of articles, I will explain how to set up integration tests in Maven starting the series by testing a simple jar and then advancing into more complex scenarios.
In a previous post entitled m2e Roadmap, Jason discussed Sonatype’s commitment to quality and testing for m2eclipse. As a follow-up, I did a quick interview with Rich Seddon and asked him some questions about Sonatype’s approach to testing for Eclipse plugins. The interview is approximately five minutes long and in this interview, you’ll here Rich give some detailed descriptions of the tools he uses to test the m2eclipse plugin.
[media id=1 width=320 height=70]
I just wanted to let people know what’s been happening with m2e recently and what we’ll be focusing on in the near term. Recently, there has been a lull in the number of releases because we have decided that testing and quality are the priority so we had to take a step back and figure out a plan of action. The primary outcome is that we feel that the infrastructure for the testing needs to take precedence in order for everything else to fall into place. New feature development has to take a back seat to make sure the current functionality is flawless in execution. Quality is our primary concern, and this means that all new features have to be backed by a completely automated tests (including automated UI tests). As we have discovered, this is an extraordinarily difficult task to accomplish. Provisioning target platforms, meshing Tycho with Hudson for CI/Releases, and automating UI tests is not simple by any stretch of the imagination.
Nonetheless we’re committed to the task and we’ve hired Rich Seddon to create the testing framework and infrastructure. Our goal is to reach the standard set by Nexus which has so many integration tests that virtually nothing regresses and we can refactor and add new features without introducing new bugs. Unfortunately, we know from experience in our training classes and feedback from users that m2eclipse has not reached this level of quality and we are fully addressing this fact by committing ourselves to testing and quality. We probably should have pursued fewer features and more testing, but what’s done is done. From this point forward, testing is our primary concern. We will be able to add some new features, and do some architectural work to help stabilize m2e for the 1.0 but we’re basically going to be eradicating defects and adding the testing which will facilitate the convergence of m2e with the current Maven trunk and ultimately the Maven 3.0 final release. In this post, I’ll walk through what we’re doing at a high level and then try to layout a schedule for what’s going to happen in the next few months.