Skip to content

Load Testing Blog

What we did these last two weeks

It's been a busy couple of weeks but we keep doing our best to get new features in OctoPerf.

We have worked on two topics:

  • Ease of use
  • Implementing feedbacks

User experience

Some of you probably noticed but we are working to improve the first experience with OctoPerf. At first with video tutorials which show all the features: Tutorial

New features and improvements

This blog post aims to resume all the cool new features and improvements we've made to OctoPerf since the beginning of the year.

Design

Improvements and features in this section are related to the online virtual user design exclusive to OctoPerf.

Enable / Disable actions

This is a must-have to quickly rework any existing virtual user. Any action can now be disabled to prevent it from being executed when running the virtual user. Actions no longer need to be removed from the virtual user to be taken out of the execution. This feature is especially useful to debug virtual users by running repeated validations.

Enable / Disable actions

Why objects must be Immutable

Immutable objects have multiple advantages over mutable objects which makes them the perfect building block to create software. You may already have many questions about the subject like:

  • Why should I use immutable over mutable objects?
  • How can I design software where no single object can be modified?

You'll see in this article what an immutable object is, the advantages to use them every time you can and how they can speed up your software developments.

Definition

To make it simple, a class is immutable when instances of this class cannot be changed once constructed. Immutable objects follow five rules, like explained in Java Effective by Joshua Bloch:

Final fields

No internal field can be reassigned after construction. This is very important: once the object has been constructed, there is no way to modify it.

public final class Truck {
 private final String brand;
 private final String model;
  ...
}

Angular2: filtering ngFor using pipes

Angular2 / Bootstrap4 table

I'm still working on a Stripe administration console for OctoPerf, a SaaS performance testing tool. Stripe lets us manage our customers and their subscriptions.

I have a table that lists all of our customers (Customers.html):

<table class="table table-striped">
  <thead class="thead-default">
  <tr>
    <th>#</th>
    <th>Id</th>
    <th>Email</th>
  </tr>
  </thead>
  <tbody>
  <tr *ngFor="#customer of customers; #i = index">
    <th scope="row">{{i}}</th>
    <td>{{customer.id}}</td>
    <td>{{customer.email}}</td>
  </tr>
  </tbody>
</table>

It's an Angular2 application build using this excellent starter with BootStrap 4.

Angular2: hard time unit testing Http requests

To follow up on my article about TypeScript generics in Angular2, I would like to unit test my Stripe client.

It involves mocking the Angular2 Http service, and it's far more complicated than unit testing the Router service. I first tried to inject a mock of the Http service and return custom Observable responses but this led to strange errors and cumbersome code.

I quickly switched to the recommended way, using MockBackend.

The service to test

As a remainder, the service tested is a Stripe client. It makes recursive Http request to Stripe API in order to fetch customers and plans: