Implement a more robust / long term functional testing solution

First of all, we could edit the README.md file to remove the WIP tag on Functional Tests (line 102) since #19 have been merged.

Then, I planning to work on this part soon. That would be great to discuss on technologies we are planning to use to build the "long term" version. A pretty cool solution would be to create a SDK with a CLI to add endpoints in a easy way, and then run tests. Something like :

$ machinery-test add scope
> name ? workflow
> endpoint ? /w
### we can return a schema of the created tests here 

$ machinery-test add endpoint --scope workflow
> name ? users
> endpoint ? /users
> method ? GET
> is token needed ? no
> number of parameters ? 0
### we can return a schema of the created tests here 

$ cat test/workflow.yml
---
workflow:
    base: "/w"
    endpoints:
        users:
            endpoint: "/users"
            method: GET
            token: False
            parameters:
                number: 0

This example is very trivial. I am planning to work on a POC version of this solution in Python + YAML soon, I'll let you know !

Looking further, I was doing research for more robust tools for our functional testing, and I found some interesting information.

TL;DR : Rust + Hyper seems to be the best choice for developing a custom SDK.

`cURL` : long-term support, heavily used, but tricky to use

Working with cURL and, by extension, with the libcurl seems to me to be one of the best options as it is very complete, robust and highly maintained.

Although it is widely used, there are still some rare security issues we should be aware of before starting working on this part

But it also comes with several disadvantages ; I heard you were planning to use golang or rust for the production-ready version, and trying to keep a certain consistency with techno used seems to be a good practice while developing this kind of solutions.

Most programming languages offers libcurl bindings, but they are not as well maintained as the C version, and there is often better solutions to work with while working with http clients.

Hyper : A fast and correct HTTP implementation for Rust.

Hyper seems to be the best http client for Rust, with some cool advantages for production-ready code ; it is, by far, the most used and most maintained library, making him the best candidate for this solution.

But it comes with something even more interesting : as described into this AWS post, Hyper provides better memory security, thanks to Rust's performance, stability but also community.

http : Golang Package `http` provides HTTP client and server implementations.

By quickly looking for golang http clients implementations, it has revealed some issues you can encounter while trying to build a robust client : as pointed out on this post, using the default http package is kinda insecure and you need to pointlessly configure it for production-scoped applications, such as our solution.

Configuration is not that complicated, but it is always something I must consider when building this kind of applications (including human error, lack of awareness, etc. during configuration).

Conclusion

All these three solution are great for our purpose, with different advantages and disadvantages. Even if I think that Hyper is the more adapted for a robust and long-term SDK, we still need to discuss on different points.

sorry for the very long answer mate 😬

tbobm / machinery