Software Development & Design on Matthias Noback

My previous encounter with Full-Stack NL was in 2019, when I was invited by Peter Paul Keuler to talk about what I consider Advanced Web Application Architecture.

Several articles later, it turns out the little test framework has grown very fast.

The right approach to software design, in my opinion, is to work with what you have, build more functionality on top of it, then realizing there are design issues, then fixing those issues by redesigning ad hoc.

When expanding our test suite, we’ll certainly encounter the need for an assert_equals function that works with other types than real(kind=real64).

In the previous post we improved the output handling of the test runner, making output optional by using an abstract progress printer.

In the previous post we’ve successfully split the running of the tests and collecting the test results from handling those results by printing the counters and error stop-ping the test program.

Maybe we’ve been writing more “generic” code for our custom test program than expected.

In the previous post, we’ve spent some time improving a number of “temporary” tests.

How can we know that the function we wrote, works as intended?

We’ve encountered several ways of designing functions in a way that allows them to fail for some reason, without stopping the program, or making it otherwise risky or awkward to use the function.