Considering FSON Support in Fossil Test

As I continue to refine and expand the libraries under the Fossil Logic umbrella, one idea has been on my mind more and more: giving Fossil Test the ability to make use of FSON in future releases. Fossil Test, my lightweight testing framework for C projects, was built with simplicity and clarity in mind. It already provides a clean way to define, run, and report tests, but I see an opportunity to take it a step further by incorporating FSON as part of its internal and external data handling.

Why FSON Makes Sense for Testing

At its core, Fossil Test needs to represent information: test cases, results, timing data, expected values, and summaries. Right now, all of that information lives purely in memory and is output as plain text. While this is perfectly adequate for small-scale testing, it becomes limiting when the goal is to collect results over time, compare runs, or integrate with other tools.

This is where FSON could shine. By using FSON as an intermediate representation of test results, Fossil Test could produce structured, machine-readable output without sacrificing human-readable logs. That means results could be saved to disk, analyzed by external tools, or even aggregated into dashboards—all while maintaining a consistent and predictable format.

FSON for Test Cases and Fixtures

Another interesting possibility is using FSON not just for output, but for defining tests themselves. Imagine being able to describe input data, expected outputs, and configuration parameters in a FSON file, then having Fossil Test automatically load and execute them. This would make test suites easier to extend and maintain, since new cases could be added without recompiling the code.

This also opens the door to parameterized tests driven entirely by data. Rather than hardcoding a loop of similar tests, a single test function could iterate over an array of FSON objects representing cases, inputs, and expectations. This approach makes testing more declarative and more flexible.

Structured Output for Integration

One of my long-term goals is to make Fossil Test more useful for automation and continuous integration environments. Right now, it prints results to the console, which is great for local development, but not ideal for systems that need to consume results programmatically. With FSON support, Fossil Test could write structured reports that CI systems or custom tools could parse and use to generate detailed dashboards, historical performance graphs, or regression reports.

The nice part is that FSON is already designed to be small, fast, and portable, which means integrating it into Fossil Test won’t introduce a heavy dependency or slow things down unnecessarily.

Looking Ahead

This idea is still in the exploration stage, and I am not rushing to implement it just yet. My first priority is to make sure Fossil Test remains minimal and easy to use, so any FSON support will be designed carefully, with opt-in functionality that does not burden developers who just want quick, simple tests.

That said, I see real potential in this direction. FSON could be the key to making Fossil Test not just a lightweight testing framework but a testing platform—one that handles both human-readable output and structured, persistent results for deeper analysis.