FP and Testing

Overview

What types of testing do we have in a functional language? Well, the same as discussed, plus a little bit extra. When it comes to end-to-end testing, there’s no real difference. At that level, language and paradigm are implementation details. The most obvious differences are at the unit level, where our testing focus is now no longer a class but a function. More specifically, we focus on testing pure functions.

Let’s take a look at our monitoring application. What can we test? What do we want to test? An overview:

• The calls.ts isn’t interesting because we’d be testing the AWS SDK. TypeScript’s compiler offers enough certainty here (mistype the name of getMetricStatistics and we’ll immediately see a warning).
• The params.ts is important to get right, so yes, we want unit tests. Because it consists of short, pure functions, this should be easy.
• The entrypoint.ts is also useful to test, although it comes with a bit of extra complexity because we have to mock AWS calls.
• We should test the transformations.ts because it has pure functions.
• The constants.ts and types.ts aren’t very interesting. If there are any mistakes, we’ll notice them elsewhere.
• The time.ts will be tested because it only has a pure function.
• The config.ts can be tested, although the “current date” stuff doesn’t make this easy.
• As we mentioned, in general, index files for Lambda contain code that’s tedious to unit test and requires extensive effort. As such, index.ts is doable, but the added value is limited because, in this case, the compiler will be able to find most of our mistakes.

Note: We’ll once again use the original version of our application, ...