Project Lombok is an amazing Java library which makes it possible to write very concise code. It's an incredibly powerful library which uses an annotation processor to generate code behind the scene.
Let me show you a very simple example:
@Value
public class Person {
String firstname;
String lastname;
}
As mobility has been the trend these past years, all the users coming to a website do so from many different devices. OctoPerf allows you to simulate traffic to your website, but it also allows to simulate this kind of multi-device traffic.
That being said, to take advantage of OctoPerf possibilities, you might need to import several different user journeys. Because a mobile user is very likely to deal with a different version of the application. Thus if you record only one user journey from a computer's browser and use it for your tests, they may not be realistic.
To record the traffic from a mobile application, you have several options. For browser based apps, you can record them from Chrome or firefox and just use the dev tools to switch the user agent:
Native apps are a bit more complex to get by.
Let's see what is required step by step to record such an application.
In our previous article, Building Better Software, we have already shown how clean we try to maintain our codebase. We strongly believe that it's possible to run a successful business and have clean code at the same time. While it's relatively easy to show some nice metrics a single time, it's much hard to keep your code clean over time.
Even if we release some major features like On-Premise load testing, we still follow the boy scout's rule: Always leave the campground cleaner than you found it. Clean Code is not only compatible with business needs, it's almost mandatory if you want to be quickly competitive on a given market.
Unlike most software companies who don't really care about the quality of the software they ship, we do care that you get the best bang for the buck load testing tool. Do you know any other software company which regularly publishes code quality metrics? Probably not. We're trying here to introduce a new movement in favor of clean code.
Clean code focus developing software that's easy to read, maintain and evolve. Good programmers have quickly understood that we are writing code for humans, not computers. Dikjstra, a famous mathematician, told something very interesting in 1972 at the Turing Award Lecture:
We're proud to announce that we released our Jenkins / Hudson plugin to run load tests from your favorite Continuous Integration / Continuous Delivery service. The sooner you detect a performance issue the quicker the bottleneck can be found and fixed.
We believe that Continuous Integration Load Testing is the key to help companies deliver high performance web applications in time. Applications today not only need to pass unit and integration tests to ensure proper operation, but also acceptance tests like performance tests to ensure it behaves correctly under load.
The new OctoPerf Jenkins plugins allows you to leverage the power of our hybrid cloud / on-premise load testing solution as part of your development / testing build cycle. This significantly simplifies load testing web application for developers and testers. Each load test can leverage the power of our infrastructure to run thousands of virtual users.
Our highly scalable infrastructure will take care of launching as many virtual users as you need every time you run a Jenkins build. It makes load testing large scale web applications on a regular basis significantly easier.
The rise of cloud platforms lead to a major evolution for load and performance testing. Since generating load requires a powerful infrastructure for a short period of time, one might even argue this is the perfect use case. But since we started OctoPerf we had a lot of feedback from users wanting to test from their own machines for a lot of good reasons.
First of all, not all web applications are available on the internet. In particular test environments, which are usually mostly meant to be used internally. As testing the application before its deployment is important, the load tests are often done on such environments.
Also, large companies have a wide range of intranet applications that can't be accessed from outside their network. Of course they need tests and in that case testing from the cloud does not make much sense.