DEV Community: Wayne Van Son

Confidence testing at scale

Wayne Van Son — Mon, 13 Feb 2023 03:42:53 +0000

Ever wondered how far we can or should take testing? What about scaling tests to millions of cases? I know I have.

I've been using, contributing and creating libraries related to testing for the past 2 years and would like to share some insights.

Please note that in this post I won't go into much detail of the code, as I would like to extend this topic over multiple posts.

What should we test?

Everything. Test it all. We need confidence in 100% of the software, so we need 100% coverage for any code that the user directly or indirectly interacts with.

Your users and customers don't want to deal with bugs, and proper testing can minimize those chances.

Overview

I'll be using the following tools throughout these sessions:

Name & Link	Purpose
typescript	Writing code and tests with types
jest	Test runner, assertion library
fp-ts-quickcheck	Property Based Testing
fast-check	Property + Model Based Testing
wdio	End to end testing framework

Types of testing

All automated testing I've seen are covered by the following combinations of characteristics:

Level:
1. Unit
2. Integration
3. End to end
Bases:
1. Static
2. Property Based
3. Model Based

The higher the number, the more effort is required and confidence is gained, where the max is a model based end to end test.

These two characteristics are mutually inclusive. A <level> test can always be a type of <base> test.

Levels

Unit Testing

The smallest thing to test. This is usually a function, testing if the specified inputs provide the resulting output.

We can test side effects and contracts between modules by mocking their interfaces, but this should be used as a last resort.

Integration Testing

A black box, where we can only see the input and we observe what happens.

At a module level, we would test the functions provided by the module and assert if the behaviour worked as expected.

It's likely that inside the function, there is a lot that happens. It doesn't matter what happens inside the function, because these will be tested in unit tests.

End to End testing

The entry point is at the highest level in the system as possible. In an application used by users, it's testing that interacting with the software results in it's natural environment provides the expected output.

Bases

This is my favourite and most interesting part of testing, and where most of the weight of scaling and confidence appears.

Static

Nothing is generated for the test.

This style of testing uses hard coded data as the input to the test. It's super useful when creating a base for your test, or when there is a particular use case.

This is the testing we all know and have probably used.

Property Based Testing

The information is generated for the test.

Example below generates a kebab-case word, and runs many different variations. It stops when one case fails, and this library will even try find the smallest failing case.

import * as fc from 'fast-check'

const isKebabCase = (string: string): boolean =>
 { /* ... implementation */ }

const kebabCase = fc
  .array(fc.lower({ minLength: 1 }), { minLength: 1 })
  .map(array => array.join("-")) 

test('should return true when the input is kebab case', () => {
  fc.assert(fc.property(kebabCase, (kebab: string) => {
    const result = isKebabCase(kebab)  
    expect(result).toBeTruthy()
  }))
})

Model based testing

The information and usage of the tool is generated for the test.

For example if you have a class with 5 methods, where:

1 method is a constructor
3 methods are combinators
1 method is a destructor

We would be to start with the constructor first, use any number of combinators any number of times, then finish with a destructor.

This is expected behaviour by the consumer, and we should be able to test that too.

In Summary

Let's put the possible back in testing all possible use cases.

It may seem tedious and take a long time, but it does not have to be that way. With the right tools and techniques, we can create thorough and purposeful coverage.

Haskell Development on VoidLinux: A match in heaven and hell

Wayne Van Son — Tue, 23 Mar 2021 07:19:45 +0000

I'm a huge fan of voidlinux. As it's my daily driver, it taught me to get good at linux and the phenomonal tools within it's ecosytem.

Let's go through the process at this point in time and see if we can get a working Haskell environment in place.

Stack as a sandbox: the easy way

If you're a voidlinux advocate, you'll note that this is not what you want. It takes up lot's of space and it's far easier than it should be.

However this will get you going.

1. Uninstallation

DO NOT install the following. If you have any of these, uninstall them.

ghc
cabal-install
haskell-language-server

Stack will install a ghc and cabal-install when you call stack in your project directory. It will find the correct tools based on the resolver property in your stack.yaml file.

2. Installation

DO install the following.

stack
ncurses-libtinfo-devel

stack is the tool of choice for managing haskell projects.
ncurses-libtinfo-devel provides the file /lib/libtinfo.so and related symbolic links. Without it, stack doesn't know what the architecture of your machine is and cannot build GHC.

3. haskell-language-server

Install the haskell language server for your IDE. In vscode, it's called Haskell.

4. Open IDE

Stack should now work flawlessly for all projects.

When a project is opened in your vscode, the Haskell extension will download and install the appropriate GHC and Cabal versions.

Binaries: the hard way

Well you asked for it, binaries built purely for your architecture.

1. Installation

Install the following packages from the voidlinux repositories.

ghc
stack
cabal-install
haskell-language-server

If all went well, skip step two because haskell-language-server has been added to the list of available packages.

2. build haskell-language-server

This is complicated for new users, but for voidlinux veterans this should be very fun indeed.

In summary, you'll process the following instructions:

clone void-linux/void-packages from GitHub.
pull and rebase the patch from branch package/haskell-language-server at https://github.com/waynevanson/void-packages.
Build haskell-language-server for your machine, which is now available due to the step prior.
Install the package post build with xi from xtools.

3. Enjoy!

Stack should now work great in all projects that have can build with ghc-8.8.4. If your project does not use this, you'll have to use the easy method instead.

Conclusion

This is extremely rushed but I hope it helps someone if they're in need of this. I had no one.

Please email me at waynevanson@gmail.com if you require guidance. Hopefully haskell-language-server is in the packages by then and this article can be streamlined.

fp-ts: Development of fp-ts-webdriver

Wayne Van Son — Wed, 17 Feb 2021 08:05:05 +0000

Phenomenal Photo by Tobias Keller on Unsplash

I've been looking to use fp-ts to communicate with a webdriver, called fp-ts-webdriver. I love the API because it allows the reduction of side effects and creates testable code.

Here is a non-exhaustive list of challenges across the way, hoping the problem solving process may aid you in your challenges.

Why

There are so many webdriver frameworks out in the abyss. Why bother writing another? Why not just wrap an existing client side API in fp-ts?

I already tried it. It sucks:

Imperative code is hard to follow (now that I've indulged in functional programming).
The async/await syntax is terrible to work with. then().then().then()
Because promises aren't lazy, they cannot be easily composed.

Challenges

Understanding the Webdriver

The webdriver protocol is a specification written by W3C, the officially standards body of the web. The specification indicates a client-server relationship, just like when we send a message to a server and the server sends back information, like a webpage. We are the client (or local end) and the server is the remote end.

The client sends a request (a webdriver command) to the remote web driver, as advised in the specification. The remote end processes the request, performs the actions you have asked, then sends back an error or a success response, as advised in the specification.

As a web developer, you're likely to have seen the client-server relationship in action many times prior.

Choosing how to compose the API

Asynchonous Composition

In fp-ts and functional programming, we use monads to compose actions.

In our case, we want to:

Compose the sending of requests to the remote webdriver (server).
- Send a request.
- Receive the response.
- If a successful response (200), send the next request
- If it's an unsuccessful response (<200 && >=300), return an error (without throwing of course) and do not send another request issued by the user.
- ALWAYS cleanup any resources (eg. An open session)

I knew I was going to use the fetch API to send a request, which returns a promise that may return an error. The monad of choice is TaskEither. A Task is a lazy promise and an Either is monad with 2 mutually present values, meaning it's either one value or the other.

Here's an article I wrote to prime you for Either.

Dependency Injection

We have a few values we don't quite know their exact values as of yet. I want to expose these as options for the user, so they can choose the endpoint (url) and change the RequestInit so they could use a proxy or do any other HTTP configuration that I don't know of yet.

In fp-ts, use the Reader monad for composing dependency injection. All it is a function that always takes the same argument <R, A>(dependency: R) => A. To inject more than one, use a tuple or an object. We'll use an object so we can name our properties.

Our monad is now ReaderTaskEither, where the Reader is wrapped around TaskEither.
This feels good! Can we go further?

Session Composition

YES! We can go further.

I noticed that the session was always an argument in the functions I needed. Not in all of it, but with 80% of the functions. This is a dependency. You know what we do with dependencies? We apply (inject) them!

Instead of merging our dependencies, let's keep them separate. Refactored, we have now created a new monad, never before seen by fp-ts: ReaderReaderTaskEither.

It sounds like we're going over the top, and it does seem like we've gone bananas...

But you wanted to control a browser right? That's a lot of responsibility. We need the power of functional programming!

With great responsibility comes great power.

Runtime type safety

We know the shape that the response should be in Success<A> = {value: A}, where A could be anything. When we know the shape of A at compile time, how do we ensure that every response we use is the right type at runtime? Imagine getting response 500 instead of 200, in which the responses body is not type Success<A>. Ouch.

If you know the fp-ts ecosystem well, you'll know we're using our boy io-ts to ensure that the typescript you see in your project will be GUARANTEED at runtime. We'll be using the Decode module.

This uses the Either monad ,as discussed earlier. This lifts easily into *TaskEither via Kleisli Composition, which we'll use internally.

Boilerplate

This is where we start to apply all the previous content in this post.

After a while, we start to see a pattern emerge. We're copying and pasting a lot of code. Some copy and paste is expected, as we're writing a uniform API. However, you'll know what to refactor to after doing it 6 TIMES.

If you get one take from this, it is that you must repeatedly write code to truly understand how and why you're able to refactor it.

I created a make function, which takes a decoder, method, endomorphicURL and maybe a body. Endomorphism is <A>(a: A) => A; The input type is the same as the output type. We use a string for this property.

Reading a Specification

Now specifications are supposed to clear and normative. Let's try decipher one together.

The remote end steps are:

Let data be the result of getting a property named cookie from the parameters argument.

If data is not a JSON Object with all the required (non-optional) JSON keys listed in the table for cookie conversion, return error with error code invalid argument.

- Add Cookie

The server (remote) expects to see at least the following the body of the response: { cookie: { name: "", value: "", path?: "", ... rest } }.
I won't list the rest, but you can see them in the table for cookie conversion

It's a lot of jargon, but after a while it's like a second language.

Testing a webdriver

This hit me for a six at the start.

In jest, we need to call beforeAll() to spin up a webdriver (chromedriver in our case) and afterAll() to spind down the webdriver.

On my local machine, it opens up an actual browser and I can see it do the tests. What if we don't want that when it's running on CI? Welcome to headless.

I had to squeeze together a bunch of resources to find this fix, so here's the code:

const capabilities: Capabilities = {
  alwaysMatch: {
    "goog:chromeOptions": { args: ["--headless"] },
  },
}

Now all the setup is done, I can just write a test for a feature.
If it works, it's ready to ship!

Publishing

I've published a few libraries, but I knew I needed to automate this one.

I conjured up GitHub Actions alongside semantic-release. The only thing I have to do is use git correctly, run git pull --rebase before running git push in order to get. You should be doing this anyway, depending on your workflow.

I get an iterative change log, a published NPM package and a release on GitHub without even having to think about publishing. Phenomenal!

haskell-language-server to void-packages

Wayne Van Son — Sun, 17 Jan 2021 05:30:21 +0000

I neded the haskell-language-server installed on my machine so I can edit *.hs files in VSCode so I get features like intellisense and syntax highlighting.

I'll go through the steps I took in order to troubleshoot and get a working version of haskell-language-server for x86_64, then additional fixes used in attempt to make it cross compile to armv7l and others.

I wrote a basic template for void-packages:

# Template file for 'haskell-language-server'
pkgname=haskell-language-server
version=0.8.0
revision=1
archs="x86_64"
build_style="haskell-stack"
short_desc="Haskell Language Server: Integration of ghcide and haskell-ide-engine"
maintainer="Wayne Van Son <waynevanson@gmail.com>"
license="Apache-2.0"
homepage="https://github.com/haskell/haskell-language-server"
distfiles="https://github.com/haskell/haskell-language-server/archive/${version}.tar.gz"
checksum="5ff053f0f4bb26b867fdc0b4071ba25c47eaa6febc9a4ef5b70a5a31c9433671"

The most important part besides the source files is build_style="haskell-stack". This provides us with do_build() and do_install() hooks that force the correct versions of stack and ghc (Glorious Haskell Compiler).
We use this because the codebase we're compiling is a haskell codebase.

Dependencies

The documentation states that that:

On Linux you will need install a couple of extra libraries:

Unicode (ICU)

NCURSES

Zlib

Let's add these dependencies as make-depends

# Template file for 'haskell-language-server'
pkgname=haskell-language-server
version=0.8.0
revision=1
archs="x86_64"
build_style="haskell-stack"
makedepends="ncurses-libtinfo-devel icu-devel zlib-devel"
short_desc="Haskell Language Server: Integration of ghcide and haskell-ide-engine"
maintainer="Wayne Van Son <waynevanson@gmail.com>"
license="Apache-2.0"
homepage="https://github.com/haskell/haskell-language-server"
distfiles="https://github.com/haskell/haskell-language-server/archive/${version}.tar.gz"
checksum="5ff053f0f4bb26b867fdc0b4071ba25c47eaa6febc9a4ef5b70a5a31c9433671"

We've got everything we need as a base, so let's kick of a build with

# initialize `masterdir`, contains `/{etc,lib,usr}`
./xbps-src binary-bootstrap
# trigger a build of the package
./xbps-src pkg haskell-language-server

Let's figure out our first errors.

Errors

Error: Out of Memory

This is a problem with your machine, not the package or the compiler.

Run ./xbps-src pkg haskell-language-server to continue where it left off. If any files where compiled, they'll be reused and not recompiled.

If you run ./xbps-src pkg -f haskell-language-server they will be recompiled. I use this when I've made changes to the template that affect the build/install stages.

That's an easy fix, phew!

Error: Haskell related.

We're getting a lot of errors from the codebase, which is unusual in a working package. This is because we're not using the latest version of ghc, but one with long-term support (lts).

Running ghc --version points to version 8.8.4, which indeed is the GHC-lts at this point in time.

I noticed that the source files come with a bunch of stack-(n-n-n).yaml files. The version number indicates which version of GHC we need to use.

We need to use that one instead of stack.yaml, which was done by default.

To use stack-8.8.4.yaml, we need to pass a flag to the stack build and stack install commands. We can do this by assigning the stack flags to the variable make_build_args:

# Template file for 'haskell-language-server'
pkgname=haskell-language-server
version=0.8.0
revision=1
archs="x86_64"
build_style="haskell-stack"
make_build_args="--stack-yaml stack-8.8.4.yaml"
makedepends="ncurses-libtinfo-devel icu-devel zlib-devel"
short_desc="Haskell Language Server: Integration of ghcide and haskell-ide-engine"
maintainer="Wayne Van Son <waynevanson@gmail.com>"
license="Apache-2.0"
homepage="https://github.com/haskell/haskell-language-server"
distfiles="https://github.com/haskell/haskell-language-server/archive/${version}.tar.gz"
checksum="5ff053f0f4bb26b867fdc0b4071ba25c47eaa6febc9a4ef5b70a5a31c9433671"

Let's build again using ./xbps-src pkg -f haskell-language-server and see what we get next.

Error: nopie

We're getting some crazy errors about the executables not being pie files. Here is the Wikipedia Article for reference.

The fix is that for every executable, we must specify the path to executable files produced by the do_install().

# Template file for 'haskell-language-server'
pkgname=haskell-language-server
version=0.8.0
revision=1
archs="x86_64"
build_style="haskell-stack"
make_build_args="--stack-yaml stack-8.8.4.yaml"
makedepends="ncurses-libtinfo-devel icu-devel zlib-devel"
short_desc="Haskell Language Server: Integration of ghcide and haskell-ide-engine"
maintainer="Wayne Van Son <waynevanson@gmail.com>"
license="Apache-2.0"
homepage="https://github.com/haskell/haskell-language-server"
distfiles="https://github.com/haskell/haskell-language-server/archive/${version}.tar.gz"
checksum="5ff053f0f4bb26b867fdc0b4071ba25c47eaa6febc9a4ef5b70a5a31c9433671"
nopie_files="
/usr/bin/haskell-language-server
/usr/bin/haskell-language-server-wrapper
/usr/bin/ghcide-bench
/usr/bin/ghcide
/usr/bin/ghcide-test-preprocessor
"

Architecture Compatibility

DONE! It compiled, what a time to be alive.
void-packages/CONTRIBUTING.md explain that we should also try build for armv7l, but I always try build the following:

# defaults to `x86_64`, but never mention the
# arch if you're already using it;
# use for cross-compilation only
./xbps-src pkg -f haskell-language-server
./xbps-src -a x86-64-musl pkg -f haskell-language-server
./xbps-src -a armv7l pkg -f haskell-language-server
./xbps-src -a aarch64 pkg -f haskell-language-server
./xbps-src -a i868 pkg -f haskell-language-server

`armv7l`

We purposefully restricted the architecture to x86_64, let's add aarch64 to the archs variable.

# Template file for 'haskell-language-server'
pkgname=haskell-language-server
version=0.8.0
revision=1
archs="x86_64 aarch64"
build_style="haskell-stack"
makedepends="ncurses-libtinfo-devel icu-devel zlib-devel"
short_desc="Haskell Language Server: Integration of ghcide and haskell-ide-engine"
maintainer="Wayne Van Son <waynevanson@gmail.com>"
license="Apache-2.0"
homepage="https://github.com/haskell/haskell-language-server"
distfiles="https://github.com/haskell/haskell-language-server/archive/${version}.tar.gz"
checksum="5ff053f0f4bb26b867fdc0b4071ba25c47eaa6febc9a4ef5b70a5a31c9433671"

New build, let's run ./xbps-src -a aarch64 pkg -f haskell-language-server.

Error: `ncursesw`

It looks like we cannot find the ncursesw resource on this particular architecture. My experience indicates it's usually fixed with ln -sf /lib/libtinfo.so.5 /libtinfo.so.6, but the fix is for ncursesw, not tinfo so we will put the fix inside of the pre_build() hook.

# Template file for 'haskell-language-server'
pkgname=haskell-language-server
version=0.8.0
revision=1
archs="x86_64 armv7l"
build_style="haskell-stack"
make_build_args="--stack-yaml stack-8.8.4.yaml"
makedepends="ncurses-libtinfo-devel icu-devel zlib-devel"
short_desc="Haskell Language Server: Integration of ghcide and haskell-ide-engine"
maintainer="Wayne Van Son <waynevanson@gmail.com>"
license="Apache-2.0"
homepage="https://github.com/haskell/haskell-language-server"
distfiles="https://github.com/haskell/haskell-language-server/archive/${version}.tar.gz"
checksum="5ff053f0f4bb26b867fdc0b4071ba25c47eaa6febc9a4ef5b70a5a31c9433671"
nopie_files="
/usr/bin/haskell-language-server
/usr/bin/haskell-language-server-wrapper
/usr/bin/ghcide-bench
/usr/bin/ghcide
/usr/bin/ghcide-test-preprocessor
"

pre_build() {
    # fixes `/usr/bin/ld: cannot find -lncursesw`
    if [ "$XBPS_TARGET_MACHINE" != "x86_64" ] && [ -f "/lib/libncursesw.so" ]; then
        ln -sf /lib/libncursesw.so.6.2 /lib/libncursesw.so
    fi
}

A haskell dependency was looking for /lib/libncursesw.so, so we created a symbolic link (like a shortcut in Windows) to /lib/libncursesw.so.6.2.

Running ./xbps-src pkg haskell-language-server brings us to our next error.

Error: `network`

This is as far as I got with the armv7l version. It's also a problem on all the others.

Now I'm not sure what to do here.

network                          > configure
network                          > [1 of 2] Compiling Main             ( /tmp/stack-8ee1647aa5b6024f/network-3.1.1.1/Setup.hs, /tmp/stack-8ee1647aa5b6024f/network-3.1.1.1/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/Main.o )
network                          > [2 of 2] Compiling StackSetupShim   ( /builddir/haskell-language-server-0.8.0/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack-8ee1647aa5b6024f/network-3.1.1.1/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/StackSetupShim.o )
network                          > Linking /tmp/stack-8ee1647aa5b6024f/network-3.1.1.1/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup ...
network                          > Configuring network-3.1.1.1...
network                          > configure: WARNING: unrecognized options: --with-compiler
network                          > checking build system type... x86_64-pc-linux-gnu
network                          > checking host system type... x86_64-pc-linux-gnu
network                          > checking for gcc... /usr/bin/cc
network                          > checking whether the C compiler works... no
network                          > configure: error: in `/tmp/stack-8ee1647aa5b6024f/network-3.1.1.1/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/build':
network                          > configure: error: C compiler cannot create executables
network                          > See `config.log' for more details

Either: fp-ts

Wayne Van Son — Sat, 05 Dec 2020 04:09:22 +0000

Photo by Toby Elliott on Unsplash

Introduction

I received an email from an Aussie admirer of my last post asking for part two of the series.
Deja Vu, here we are again with another fp-ts data structure for handling conditional logic.

We've already explored the data structure Option<A> as a functional replacement to handle if statements.

Today we'll gear our minds towards handling what happens when if needs an else.

Signature

type Either<E, A> = Left<E> | Right<A>;

interface Right<A> {
  _tag: "right";
  value: A;
}

interface Left<E> {
  _tag: "Left";
  value: E;
}

Left and Right can be distinguished with the _tag property on the object, which is available at runtime. It's leveraged by the functions within the module to map over.

replace `if`/`else` with `Either`

Our goal will be to create a Person struct, where the constraint is that a name must be letters only, no spaces, no numbers.

If it does not match this, we need options to handle it (functionally).

interface Person {
  name: string;
}

Using the language

function validateName(name: string): string {
  // regex for letters only
  if (/[a-zA-z]/.test(name)) {
    return name;
  } else {
    return "not a valid name!";
  }
}

We can use the ternary operator to make this a lot smaller, but the logic is the same.

const validateName = (name: string): string =>
  /[a-zA-z]/.test(name) ? name : "not a valid name!";

Did you notice the return value is string, regardless of whether it is valid or not?

If we wanted to differentiate the return value with the same type (string, number, etc), we must put it in a box/data structure.

Using fp-ts

Let's use the Either data structure and see how it looks.

Constructors

import { either as E } from "fp-ts";

// (name: string) => Either<string, string>
const validateName = E.fromPredicate(
  (string: string) => /[a-zA-z]/.test(string),
  (name) => `"${name}" is not a valid name!`
);

fromPredicate is a function derived from the MonadThrow typeclass.

It is a constructor, meaning it can create the data structure. In this case it creates an Either using a predicate function.

Combinators

Now because we're using a data structure with the familiar fp-ts API, we have access to all other combinators applicable to this structure.

These can be found here:

https://github.com/gcanti/fp-ts/blob/9ff0cb6a7264c03254ff60232fb44dba3841a340/src/Either.ts#L1262-L1290

We'll use the functions map and mapLeft, derived from the MonadThrow typeclass.

// example of inline function composition
import { either as E } from "fp-ts";
import { flow } from "fp-ts/function";

interface Person {
  name: string;
}

// (name: string) => Either<string, Person>
const makeUser = flow(
  E.fromPredicate(
    (name: string) => /[a-zA-z]/.test(name), 
    (name) => `"${name}" is not a valid name!`
  ),
  // applies the function over `Right`, if it is `Right`
  E.map((name): Person => ({ name })),
  // applies the function over `Left`, if it is `Left`
  E.mapLeft((message) => new Error(message))
);

Nothing stops us from composing our functions inline as demonstrated.

Since we're using functions, let's split out some inline functions. We do this when we need to use them elsewhere in our hypothetical code base or if it's easier for you to read.

// example of separated functional composition
import { either as E } from "fp-ts";
import { flow } from "fp-ts/function";

interface Person {
  name: string;
}

const regexLetters = /[a-zA-z]/;

// (name: string) => Either<string, string>
const validateName = E.fromPredicate(
  (name: string) => regexLetters.test(string),
  (name) => `"${name}" is not a valid name!`
);

const makeError = (message: string) => new Error(message);

// (name: string) => Either<Error, Person>
const makeUser = flow(
  validateName,
  E.map((name): Person => ({ name })),
  E.mapLeft(error)
);

Beautiful. Now we can use these functions where ever we may. The most useful I think is regexLetters and makeError

Destructors

Well there are a few destructors available, so we'll use the fold and getOrElse functions.

fold takes two functions, where the first is a case for Left and the second is a case for Right.

// using fold
import { either as E } from "fp-ts";
import { flow } from "fp-ts/function";

interface Person {
  name: string;
}

const regexLetters = /[a-zA-z]/;

const validateName = E.fromPredicate(
  (name: string) => regexLetters.test(regexLetters),
  (name) => `"${name}" is not a valid name!`
);

const makeError = (message: string) => new Error(message);

const makeUser = flow(
  validateName,
  E.map((name): Person => ({ name })),
  E.mapLeft(makeError)
);

// (name: string) => string
const main = flow(
  makeUser,
  E.fold(
    (error) => error.message,
    ({ name }) => `Hi, my name is "${name}"`
  )
);

expect(main("Wayne"))
  .toMatchObject(E.right(`Hi, my name is "Wayne"`));

expect(main("168"))
  .toMatchObject(E.left(`"168" is not a valid name!`));

An alternative option is to use getOrElse, which we can use if we don't need to change the output of the Right value in Either

// using getOrElse
import { either as E } from "fp-ts";
import { flow } from "fp-ts/function";

interface Person {
  name: string;
}

const regexLetters = /[a-zA-z]/;

// (name: string) => Either<string, string>
const validateName = E.fromPredicate(
  (name: string) => regexLetters.test(name),
  (name) => `"${name}" is not a valid name!`
);

const makeError = (message: string) => new Error(message);

const makeUser = flow(
  validateName,
  E.map((name): Person => ({ name })),
  E.mapLeft(makenerror)
);

// (name: string) => string | Person
const main = flow(
  makeUser,
  // `W` loosens the constraining result type,
  // otherwise it would force us to make it `Person` type.
  E.getOrElseW((error) => error.message)
);


expect(main("Wayne"))
  .toStrictEqual({ name: "Wayne" });

expect(main("168"))
  .toBe(`"168" is not a valid name!`);

There a few more, but these are the most common and I rarely use the rest.

Notes

I find using fp-ts scales a project way better, where enforcing the constraints of "pure" functional programming really makes a difference when practicing domain driven development.

Keep in mind it's not worth folding/destructing your data structure until you have to. Usually there is a main function that is the entry point into an application and this where most of my folding happens.

It's up to your taste if you like the functions separated or inline.
But when you need to use the same code more than twice in a code base, the separated functional approach is what you may lean towards.

Option: fp-ts

Wayne Van Son — Fri, 03 Jul 2020 11:53:23 +0000

Photo by Tom Morel on Unsplash, show him some love!

Introduction

I've fallen in love with fp-ts and the ecosystem. Once the main concepts are grasped and the code starts to flow, life is bliss. I will be very sad when my day job requires imperative style programming.

It solves many problems I've had coding, but I'll write about that another day.

One issue with the fp-ts ecosystem is that the docs are not designed for beginners; It's assumed you know the jargon and theory of functional programming.

The goal of this piece is to provide the information I was missing on my journey to aid those that may need it. If it's helpful please let me know somehow: like the post, otherwise I'm accessible via email or twitter.

We'll describe how to switch from using the built in if, else and switch keywords and using the fp-ts equivalents: Option and Either monads.

Swap `if` for our saviour, `Option<A>`

Logic gates are a core of programming. More often than not, we're trying to assert if it IS something rather than isn't. If you're not a believer, work with io-ts for a week and you too can feel the joy of non-defensive programming.

Our current options for validation are:

throw new Error() if the validation fails.
Return null if the validation fails.

We will replace these with Option<A>, which represents null as None and the non-null value as Some<A>.

Don't `throw new Error()`

Here our function of lovely ensures that our string a starts with the word "lovely", otherwise it throws an Error.

function startsWithLovely(a: string): string {
  if(!a.startsWith("lovely")) {
    throw new Error()
  }

  return a
}

expect(startsWithLovely("lovely to meet you"))
  .toBe("lovely to meet you")

expect(startsWithLovely("nice to meet you"))
  .toThrowError()

The program will stop completely, with side effects you do or don't know about still running from earlier with null values (requests, responses).

If throw errors to catch them, we'll demonstrate some pure patterns in part 2/3.

Instead, let's try the next "best thing": null.

Returning `null`

Here our function of lovely ensures that our string a starts with the word "lovely", otherwise it return null.

function startsWithLovely(a: string): string | null {
  if(!a.startsWith("lovely")) {
    return null
  }

  return a
}

expect(startsWithLovely("lovely to meet you"))
  .toBe("Lovely to meet you")

expect(startsWithLovely("nice to meet you"))
  .toBe(null)

Our startsWithLovely function is now pure (nothing outside the function is changed).

The problem now is that we have to check that the value returned is not null whenever we want to use it. How annoying!

Our saviour, `Option<A>`

In functional programming, null is not used. The short story is that it was a mistake that gets worse in Javascript, because typeof null === "object".

It's not obvious in these examples because we're working with primitives like string and boolean. Once we start mixing null and Javascript objects together, it'll feel like running with arthritic knees.

The Option<A> is one of the most common types (boxes) you'll use.

import { option as O } from "fp-ts"

function oStartsWithLovely(a: string): O.Option<string> {
  if(!a.startsWith("lovely")) {
    return O.some(a)
  }

  return O.none
}

An improvement on this would be to use ternary operators, but instead we can use the constructor O.fromPredicate.

import { option as O } from "fp-ts"

function oStartsWithLovely(a: string): O.Option<string> {
  return O.fromPredicate(s => s.startsWith("lovely"))(a)
}

Or even one better:

import { pipe } from "fp-ts/lib/function"
import { option as O } from "fp-ts"

const startsWithLovely = (a: string): boolean =>
  a.startsWith("lovely")

const oStartsWithLovely = O.fromPredicate(startsWithLovely)

Note that oStartsWithLovely has the signature (a: string) => O.Option<string> across all three examples above.

Composition with `Option`

Now we know when to use Option, let's look at how we can use it.

Our goal is to validate a string. It must meet all these conditions:

start with "lovely".
contain "meet".
end with "you".

The way we'd usually do this is with if and returning null, only returning the input value if it passes all the checks.

const example = (a: string): string | null => {
  const conditions = 
    a.startsWith("lovely") ||
    a.endsWith("you") ||
    a.includes("meet")

  if (conditions) {
    return a
  }

  return null
}

This might look normal to you. It did for me. Since we can control our own destiny, let's look at a few ways to use Option.

Chain

Chain works analogously to Array.map then Array.flatten, but instead of an Array<A> we'll use Option<A>.

import { pipe } from "fp-ts/lib/function"
import { option as O } from "fp-ts"

const startsWithLovely = (a: string) =>
  a.startsWith("lovely")

const endsWithYou = (a: string) =>
  a.endsWith("you")

const containsMeet = (a: string) =>
  a.includes("meet")

const oExample = (a: string | null) =>
  pipe(
    a,
    O.fromNullable
    O.chain(O.fromPredicate(startsWithLovely)),
    O.chain(O.fromPredicate(endsWithYou)),
    O.chain(O.fromPredicate(containsMeet)),
  )

This is a lot better, but you see the pattern right? We're using O.chain(O.fromPredicate(condition))) over and over.

What if had to have 20 validation checks? copy-pasta should not the solution.

Let's refactor this with what might feel like pure magic.

import { pipe } from "fp-ts/lib/function"
import {
  option as O,
  array as A,
} from "fp-ts"

const startsWithLovely = (a: string) =>
  a.startsWith("lovely")

const endsWithYou = (a: string) =>
  a.endsWith("you")

const containsMeet = (a: string) =>
  a.includes("meet")

const conditions = [
  startsWithLovely,
  endsWithYou,
  containsMeet
]

const oExample = (a: string) =>
  pipe(
    conditions,
    // conjunction: all must be `Some`
    A.reduce(O.some(a), (oPrev, condition) =>
      pipe(
        oPrev,
        O.chain(O.fromPredicate(condition))
      )
    )
  )

This is putting all condition checkers in an array and iterating over each one, returning the results.

If you're coming from a non-functional background, this is a much better example than using and A.foldMap(monoidAll)(condition => condition(a))(conditions).

Parting words

This might seem like a jump in complexity, and it is to some extent. For simple examples it can be overkill, but what about more complex examples? The demand to create increasingly complex applications requires smarter, higher level abstractions. Functional programming fits abstraction neatly at a low level: code.

Programmers usually sit around the 85% percentile, so it's fair to say that we have the intellect to handle the abstraction. Some really smart people have conjured up the beauty of category theory, so let's follow in their footsteps.

If this helpful, I encourage you to utilize the functional paradigm and make the "boring" jobs fun again!

Part two will be on it's way soon.

DEV Community: Wayne Van Son

Confidence testing at scale

What should we test?

Overview

Types of testing

Levels

Unit Testing

Integration Testing

End to End testing

Bases

Static

Property Based Testing

Model based testing

In Summary

Haskell Development on VoidLinux: A match in heaven and hell

Stack as a sandbox: the easy way

1. Uninstallation

2. Installation

3. haskell-language-server

4. Open IDE

Binaries: the hard way

1. Installation

2. build haskell-language-server

3. Enjoy!

Conclusion

fp-ts: Development of fp-ts-webdriver

Why

Challenges

Understanding the Webdriver

Choosing how to compose the API

Asynchonous Composition

Dependency Injection

Session Composition

Runtime type safety

Boilerplate

Reading a Specification

Testing a webdriver

Publishing

haskell-language-server to void-packages

Dependencies

Errors

Error: Out of Memory

Error: Haskell related.

Error: nopie

Architecture Compatibility

armv7l

Error: ncursesw

Error: network

Either: fp-ts

Introduction

Signature

replace if/else with Either

Using the language

Using fp-ts

Constructors

Combinators

Destructors

Recommended Reading

Notes

Option: fp-ts

Introduction

Swap if for our saviour, Option<A>

Don't throw new Error()

Returning null

Our saviour, Option<A>

Composition with Option

Chain

Parting words

`armv7l`

Error: `ncursesw`

Error: `network`

replace `if`/`else` with `Either`

Swap `if` for our saviour, `Option<A>`

Don't `throw new Error()`

Returning `null`

Our saviour, `Option<A>`

Composition with `Option`