|
Written by Greg George
|
|
Tuesday, 17 March 2009 |
As mentioned in other Attivio blogs, we use many tools in our agile development environment, including Ant and JUnit. We have over 4000 JUnit tests and rely on them to keep our code robust and allow us to quickly deploy quality releases. One obstacle we hit when running our continuous and nightly tests was in determining how to deal with test timeouts and long running tests. Currently JUnit supports setting timeouts on a per-test basis with the @Test(timeout=n) annotation. In addition, the JUnit Ant Task has a parameter, timeout=n, which allows for test timeouts managed outside of JUnit.
Both of these timeout solutions have a serious flaw in that neither gives enough information to help debug what went wrong or was going on when the timeout occurred. After getting occasional timeouts on different tests with no way of understanding why, we decided to enhance JUnit with two new features. We added a capability to set a default timeout for all JUnit tests, and a capability to capture the stack trace of all threads active at the time of the timeout.
Luckily, JUnit 4.5 has the ability to easily override some of its core functionality allowing us to improve the timeout behavior.
|
|
|
Written by Myriam Midy
|
|
Thursday, 15 January 2009 |
When we embarked on the journey of implementing a new performance testing framework, I thought it would be a useful tool, I just did not realize how useful and how much I would enjoy solving problems with it.
Although we do a combination of manual and automated testing here (sometimes you just don't have a choice) we all firmly believe in automation and all the wonderful things it buys you: re-usability, reproducibility, consistency, etc. That's why we did not think twice about investing in implementing a framework that would help to get us to 100% automation of all our performance tests.
We started out thinking we would be writing a lot of Java code around a performance tool. We had some experience with JMeter and decided to keep using that. What we did not realize was how much we would be using Ant which we also had been using for compiling our code and running our JUnit tests. Instead of writing the Java code we thought we needed, we ended up using the very simple and convenient Ant tasks. We quickly realized that a lot of the functionality we needed was already provided by Ant! We gained a lot of time right there!
|
|
Written by Will Johnson
|
|
Thursday, 11 December 2008 |
For something that seems like the simplest task, logging in Java is one of the more hotly debated and hard to figure out issues. It's not that people don't want to log messages about what's going on, and it's not that users don't want nice messages telling them what is happening. The problem comes down to deciding exactly how to log messages. Pick your favorite open source project and add ‘logging' to a Google search and you're sure to come up with at least 10 threads with developers arguing 8 different sides of the argument.
|
|
Written by Martin Serrano
|
|
Tuesday, 18 November 2008 |
If you've been a Java programmer for long enough you've probably come across the situation where you have one API that can write to an OutputStream and you need to stitch it to another API which wants to read from an InputStream. No problem right? The Java API is large and there must be a class implements InputStream that can be constructed with an OutputStream. What? No? Well, then a quick internet search should reveal a utility class that will do the trick.
|
|
Written by Gil Novak
|
|
Wednesday, 08 October 2008 |
Attivio would like to introduce readers of our blog to our new Technical Series articles. In these articles we will explore many of the technical aspects involved in developing enterprise software in the emerging Unified Information Access market. Additionally, we will discuss some of the solutions and strategies for bringing the worlds of enterprise search and business intelligence together via our Active Intelligence Engine (AIE). In our first article, Attivio's Gil Novak provides an overview of how the Quality Assurance team is leveraging open source test tools and virtualization to test the Active Intelligence Engine (AIE) installation processes in a continous build & development environment.
|
|
|
|
|
|
