Our New user interface has kept us busy for a while now, which explains why we haven’t made an update post like this one in a while. You’ve probably noticed that the UI has changed a lot since the first version released last year. It’s obvious when you put them side by side. The beta version: And the latest: A lot of it had to do with updating to Angular 15 but this was also the perfect occasion to offer an even better user experience.

In this blog post, we will run JMeter tests from code. First we will look at how we can create an IntelliJ project in Java to build a JMeter performance test. Once you understand how JMeter tests in code can be written you can start to build tests in your development code base to compliment unit tests or functional tests written by developers during the creation of application and services.

We are going to look at how JMeter outputs to both the log panel in GUI mode and the log file in non-GUI mode. We will look at the properties relating to the GUI log panel and the Appenders and Loggers that determine what data is output and at what level the logs are output at. JMeter uses log4j to provide its logging mechanism and from the log4j website: We will look at how Jmeter configures Appenders and Loggers separately but they work together to produce the logged output.

The idea behind this blog post originated when we updated our documentation after the release of our new UI. With more than 250 blog posts at the time I’m writing this one, you can see how this could prove challenging. And of course the twist is that we also took this opportunity to reorganize the documentation so it’s not as simple as a search and replace of the domain..

We are going to look at how performance testing can work hand in hand with Artificial Intelligence and Machine Learning: As there are many Artificial Intelligence solutions to choose from and for the purposes of this post this is the easiest way to discuss the principles of Artificial Intelligence working with performance testing rather than discussing a particular framework.

This article is the last in a series of overviews of our new UI. You can find the others here: This time we will dive into the changes we’ve made in the analysis.

In this blog post we are going to look at some of the uncommon performance tests. By this we mean those scenarios that are not what we believe are commonly executed but those that are run periodically at best. These uncommon scenarios should not necessarily take priority over the more common performance scenarios. They do add value by stressing parts of your application under test that may be missed by the more conventional tests.

We have spoken in a previous blog post about documentation about how we believe that if you are building performance tests that support either Continuous Integration or Continuous Delivery then having to produce performance testing documentation before and after each test does not fit with this methodology.

When building performance tests, we all understand the value of using properties or variables to store static values outside of our tests. This ensures that any changes to these values need only be made in one place rather than having to make these changes in many tests. Sometime though you may have inherited a suite of JMeter tests, or you were ** under pressure to develop these tests** and in order to do so you hardcoded values in your tests.