Welcome to our team! Today is your first day, which means it’s the day you’ll release your first feature. You’ll see everything needed to design, implement, and release a feature in our system. We’ll touch on F# language features, our TDD style, and some architecture topics.
This blog post is part of the F# Advent Calendar 2024 (thanks, Sergey, for the organisation).
Sometimes, unit tests are really small – so small that they fit on a single line:
We use NodaTime in our application to deal with time. As you may remember, time is very important in our application – it’s a attendance time-tracking tool with duty planning and many more features. For example, we use Instant to model a point in time. But sometimes, we need a point in time with a granularity of minutes, not nanoseconds. Instead of introducing our own type to model an instant with minute granularity, we use an Instant with a measure. Let’s see how this works:
We use event sourcing in many sub-systems of our application to store data. We serialize the data of the events as JSON and store the JSON in the database. To ensure that we don’t change the structure of these event data and by this introduce backward compatibility issues, we use Verify to snapshot test the event data.
A frequent question I get is how to structure a codebase in F#. There is not much about this topic out there on the Internet. So here is how we structure our code:
Active patterns make using a Regex in F# neat: The matched groups are returned in the list after the pattern. Here is an example from our codebase:
Pattern found at Active Patterns – F# | Microsoft Learn:
When comparing complex data types in unit test assertions, for example, records with nested lists containing discriminated unions, the error messages quickly get hard to understand. How to spot a single difference?
That’s why I mixed Unquote and D-Edge.Diffract together.
An example unit test from our codebase:
F# makes it easy to model a domain with discriminated unions (= it is one of these values) and measures (type-safe numbers). Excerpt from our expenses sub-system:
Today’s random F# code from our app is about using Results instead of using exceptions.
Do you often need to get some data from the database, but it’s not sure that the requested data exists? And you don’t like using exceptions for this because exceptions are for really unusual things? Then use a Result:
Querying data with the help of Result
Today’s random F# code from our app is about validating data passed to us over our public API:
Example code showing the usage of FsToolkit.ErrorHandling’s validation computation expression.