Are you tired of struggling with flaky, slow, and complex browser automation tools? If you're a developer looking for a robust solution to automate your web testing and interaction needs, Playwright might just be the answer you've been searching for. In this blog post, we'll walk you through the process of getting started with Playwright, from installation to writing your first test script (in TypeScript).
Everywhere you look on social media its DevOps, Agile Methodologies, Continuous Integration, Continuous Delivery. You could be forgiven for believing that most organisations and programmes follow these principles.
This is not true.
Many companies use a Waterfall model which is also known as a linear-sequential life cycle model. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases. The Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap.
It is difficult to determine a percentage for the number of organisations that follow this model but its high. Probably more than half the number of software programmes follow this approach. Many companies prefer it, many companies still need to follow it.
This is due to the way that stakeholders manage the development and release of features. There are many organisations that due to regulatory reasons or compliance need to follow this way of developing and releasing software.
Many of the posts we publish focus on ways that performance testing fits into Continuous Integration and Continuous Delivery. We know that as the Waterfall model is not going to disappear any time soon so it’s time to look at how you could build performance testing for a Waterfall model. It is not correct to say that Waterfall is the way software was developed. Or Continuous Integration is the way that software should be developed. It is down to the individual organisation and the client the software is being developed for.
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. The look and feel will continue to evolve as we integrate new features, feedbacks and bugfixes but we're proud to say that the bulk of it is behind us now.
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.
In a DevOps world it is the responsibility of developers to support all development effort with a suitable and robust set of tests that are run as the code is built and deployed into the various non-prod and prod style environments and your performance tests can sit alongside these.
We have chosen to use IntelliJ due to its widespread use and we have chosen to create a Maven project to allow us to import the JMeter dependencies.
Clearly your preference may be different, but the principles remain the same.
We will build and execute this as a stand-alone project to demonstrate the principles but once you are happy with how it works there is no reason you cannot build similar performance tests in your application development codebase or even pair with the development teams to build a performance capability in your deployment pipelines.
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:
Log4j has three main components: loggers, appenders and layouts. These three types of components work together to enable developers to log messages according to message type and level, and to control at runtime how these messages are formatted and where they are reported.
We will look at how Jmeter configures Appenders and Loggers separately but they work together to produce the logged output.
The logging level can be set in several ways:
We will explore all of these during this post. Note that you can download the sample JMX here.