DEV Community: theredfish

Use Grillon to test your Rust HTTP API! 0.5.0-alpha.1 is out!

theredfish — Tue, 05 Sep 2023 23:35:00 +0000

Hey Rustaceans!

Many of you develop or maintain HTTP APIs in Rust. But writing and maintaining their tests can be a tedious task right?

With the pre-release 0.5.0-alpha.1, you can preview the built-in functions to test json path values for equality and validity with a json schema. Your feedback is important so we can better shape what you need! Give it a try by following the instructions in the Readme.

⭐ Consider to give it a star to support the project! Thanks!

theredfish / grillon

🦗 Grillon, an elegant and natural way to approach API testing in Rust.

Grillon

Grillon offers an elegant and natural way to approach API testing in Rust.

Elegant, intuitive and expressive API
Built-in testing functions
Extensible

Please note that the API is subject to a lot of changes until the v1.0.0.

Documentation

Getting started

You need Tokio as asynchronous runtime. Generally, testing libs are used in unit or integration tests so let's declare grillon as a dev-dependency.

Add grillon to Cargo.toml

[dev-dependencies]
grillon = "0.5.0-alpha.1"
tokio = { version = "1", features = ["macros"] }

Then use grillon :

use grillon::{dsl::*, dsl::http::*, json, Grillon, StatusCode, Result};
use grillon::header::{HeaderValue, CONTENT_LENGTH, CONTENT_TYPE};
#[tokio::test]
async

…

View on GitHub

Rust Testing Material

theredfish — Fri, 23 Jun 2023 14:34:01 +0000

Hey Rustaceans,

We recently published a new repository. A curated list of testing material in the Rust ecosystem. If you know good testing resources for Rust, please feel free to contribute! If you're interested you can also support the initiative by giving us a star!

owlduty / rust-testing-material

🦀A curated list of test material in the Rust ecosystem.

This repository contains a curated list of testing material in the Rust ecosystem. Feel free to contribute and add your own material.

Rust testing material means any resource in a tangible or electronic format that can be used to work or learn about testing in the Rust ecosystem. It can be distributed through any type of medium such as blogs, talks, repos, books, videos, or audios.

Inspired by @mre's Idiomatic Rust repository.

Projects

Cucumber - An implementation of the Cucumber testing framework for Rust.
Mockito - A library for generating and delivering HTTP mocks in Rust.
Nextest - The next-generation test runner for Rust.
Proptest - A property testing framework (i.e., the QuickCheck family).
Test Case - Provides procedural macro attribute that generates parametrized test instances.
Thirtyfour - A Selenium / WebDriver library for Rust, for automated website UI testing.

Articles

2021

An Introduction To Property-Based Testing In…

View on GitHub

SaaS update: Assertions

theredfish — Mon, 05 Jun 2023 10:10:25 +0000

Development continues! An important feature for developers and testers is to easily write assertions. Our interface helps them discover what can be tested and chains the assertions with a No-Code interface.

We have three major advantages:

Easy for non-techies to follow what is tested
No-code: You don't to maintain a framework, codebase, or infrastructure. Focus only on the quality of your APIs.
Discoverability: A simple list of options helps you check what can be tested.

The library used to run the tests is open source. It's written in Rust and available on the github repository owlduty/grillon.

Interested in what we build? We have a great landing page for you 😄 https://owlduty.com.

Cheers,

./owlduty

I revamped my landing page and here's what I learned

theredfish — Mon, 15 May 2023 13:28:24 +0000

Hey there, my name is Julian and I'm building Owl Duty a SaaS for developers and testers to monitor and test their APIs. After sharing my landing page with friends, developers and indie hackers I realized my copywriting wasn't good. I was too vague. So I took time to revamp my landing page and here's what I learned along with some personal tips.

🏋️‍♂️Your landing page is like an exercise

The more you refine it, the more you will improve your pitch and core value proposition. Surprisingly, creating and redoing my landing page helped me better understand what I wanted to build and what my limits were (time, money, network). My first version helped me to acquire a few early adopters, but I knew it was necessary to iterate and ultimately revamp my page to attract more people.

📝 Your copywriting should be attractive

... with catchy headlines but informative paragraphs at the same time. It should be specific without being boring. The idea is to retain your visitors' attention to the end and convert visitors to users/customers. I have to say it's really hard to balance and it may take several iterations to get it right.

🗨️ Talk about your landing page

In my case, I shared it with indie hackers, and developers (some of them are also my friends). Also, I decided to get an outside perspective and see how an almost neophyte person would understand it (almost because after 13 years together my partner understands most of the tech terms 😅). I got interesting feedback, especially on the copywriting and its clarity.

🎨 Get a good design!

I don't know about you, but when I see a generic page with a bad design I close it immediately. Why? Because the design reflects the seriousness of the solution and the passion of the founder. I revamped the design, but also replaced my generic illustrations with small placeholders describing the features listed. Screenshots work pretty well and give confidence, use them if you already have an existing product. Just make sure your design is great. As for the overall style, I tried to pick one that speaks to developers/techies as they will be my early adopters.

📲 Call to action!

There are many ways to convert visitors into customers/users, but I think a good rule of thumb for a landing page is to make sure your call to action is the first thing visible and accessible from everywhere. For this, I like to put a button in a fixed header, so that visitors can click at any time. I try to avoid asking for an email first, personal preference, but I want to be sure people buy the concept after reading my page. Plus, I don't want to be too intrusive.

👤 Who are you talking to?

Users? Leads? Early adopters? Not having a product yet, I adapted my speech and preferred to constitute a mailing list of early adopters. It's transparent, people know why they subscribe (my newsletter in this case) and it builds trust. Plus, they get a special benefit on early program products and services. Make sure your call to action is clear. If you already have a product, you can provide a sign up form instead.

⌚ Designing a good landing page takes time.

The first version took me about 1,5 days (copywriting included). The new about 1,5 weeks (new copywriting included). Don't get stuck and go for the shortest iteration at first but don't necessarily share your page publicly. Get feedback then iterate, and you'll see your business idea evolve as you start building, which should be reflected in your copywriting.

🔒 Build trust from the beginning

You will need to think about the actions and information required to be GDPR compliant: data processing, cookie policy, DPO, ... and maybe some legal notices depending on where you reside. It takes time and shouldn't be neglected for the obvious reasons of doing good but also for your brand image. Anyway you will face it sooner or later if you are serious about your business.

💡Tech recommendations

NextJS is a great framework to build good SEO and optimize your landing page (not only of course).
TailwindCSS is a great way to design UIs quickly with very short feedback loops.
I use Netlify to host my page, they have a free tier and they automatically recognize your framework. They also optimize images if you need, and provide everything for SSL certs and adding your custom domain. They also provide preview pages in your pipelines (github app) so it's easy to share and get feedback before moving to prod.
Github open sourced two fonts: Hubot-Sans and Mona-Sans I use them for readability and "tech" style.

Did you find this blog post helpful? Help me by sharing it with the developer ecosystem!

🦗Grillon: an expressive Rust library to test your HTTP APIs

theredfish — Tue, 31 Jan 2023 08:00:00 +0000

Hey there,

I just released Grillon v0.4.0 and I thought it was a good opportunity to write my first dev.to post.

About Grillon

Grillon is a Rust testing library that helps you write API tests in an expressive and natural way. It currently supports HTTP and I plan to extend it to other protocols/frameworks such as gRPC, WebSockets, SSL (certificates), TCP, UDP, ICMP.

theredfish / grillon

🦗 Grillon, an elegant and natural way to approach API testing in Rust.

Grillon

Grillon offers an elegant and natural way to approach API testing in Rust.

Elegant, intuitive and expressive API
Built-in testing functions
Extensible

Please note that the API is subject to a lot of changes until the v1.0.0.

Documentation

Getting started

Before you begin, be sure to read the book to learn more about configuring logs and assertions!

You need Tokio as asynchronous runtime. Generally, testing libs are used in unit or integration tests so let's declare grillon as a dev-dependency.

Add grillon to Cargo.toml

[dev-dependencies]
grillon = "0.6.0"
tokio = { version = "1", features = ["macros"] }

Then use grillon :

use grillon::{dsl::*, dsl::http::*, json, Grillon, StatusCode, Result};
use grillon::

…

View on GitHub

I'm currently focusing on HTTP testing features and ensuring a good developer experience (API, book, global documentation, examples). My goal is to make it easier for people to navigate the project and contribute.

An expressive API

My priority is to offer a great developer experience through an API that feels natural and intuitive to use. The v0.4.0 comes with many improvements to compose assertions with predicates.

Grillon::new("http://jsonplaceholder.typicode.com")?
  .post("posts")
  .payload(json!({
    "title": "foo",
    "body": "bar",
    "userId": 1
  }))
  .assert()
  .await
  .status(is_success())
  .status(is(201))
  .response_time(is_less_than(500))
  .json_body(is(json!({
    "id": 101
  })));

Here is the current list of assertions supported with predicates for HTTP:

status: is, is_not, is_between, is_success, is_client_error, is_server_error
response time: is_less_than
headers: is, is_not, contains, does_not_contain
body: is, is_not

Each predicate function can take one or more types compatible with the tested subject. For example with status, the is predicate accepts these different types: Range<u16> (between), u16, StatusCode.

Write your own assertion logic

While waiting for more built-in test functions (like json path for body), or if you have a specific need, you can use the assert_fn function. It allows you to access the internal representation of an http response under test through an instance of Assert.

// ...
.assert_fn(|assert| {
  assert!(!assert.headers.is_empty());
  assert!(assert.status == StatusCode::CREATED);
  assert!(assert.json.is_some());

  println!("Json response : {:#?}", assert.json);
});

Configure your logs

As I'm using the library for Owl Duty I need to output json data. I decided to make the logs configurable so you can choose what best suits your needs:

StdAssert: only prints assertion failures via std::assert macro. This is the default mode.
StdOut: prints all assertion results to standard output.
Json: formats assertion results into json output.

If you configure your log settings like this:

Grillon::new("http://jsonplaceholder.typicode.com")?
  .log_settings(LogSettings::Json);

Here is an example of json output you will get from an assertion:

{
   "left":201,
   "part":"status code",
   "predicate":"should be",
   "result":"passed",
   "right":201
}

When to use Grillon?

Mainly when you want to test live APIs, here is a non-exhaustive list:

Endpoint monitoring
Synthetic monitoring
Integration tests
Automated API calls (scripts)
E2E API tests

It really depends on your needs. The thing is, Grillon is flexible and as long as you want to automate API calls, it will be a good choice. Note however that some features are missing(*) for the moment (client certificates, HTTP 2, ...). I'm on it! If you're interested in a particular feature or would like to contribute, you can check the issues.

(*) but you can still provide your own http client and response handler by implementing the Response trait (see api doc).

What's next

As I briefly mentioned, I will first focus on the documentation and developer experience (book, examples, ...). Then I'll work on extending HTTP testing functionality, supporting more protocols, making it easier to run in pipelines and outside of Rust projects, producing logs, metrics, tracing, ... everything to deliver a production-ready test library.

Thanks for reading! Happy hacking/coding!