Is there a way to "unit test" a quarto project?

[JosephBARBIERDARNAL]

Description

Perhaps my question isn't very clear, but I'd like to be able to check that my quarto project isn't broken in the same way that we do unit tests in any software project.

For example, I'd like to test that the _quarto.yaml doesn't contain invalid keys/values, that the YAML frontmatter in my .qmd files is correct (whatever that means), and so on. There are probably other things that would be relevant to test, but these are the most intuitively (?) important.

Are there any tools built into the CLI? Or extensions that cover this specific topic? I couldn't find any resources after browsing Google.

[cscheid]

For example, I'd like to test that the _quarto.yaml doesn't contain invalid keys/values, that the YAML frontmatter in my .qmd files is correct (whatever that means), and so on.

Quarto includes a validator, so it won't render unless it considers the YAML valid (for its own notion of valid, of course. It won't be able to catch, eg, typos in author names).

If you want to run these yourself, a good way to do it is to add a pre-render script to your quarto project: https://quarto.org/docs/projects/scripts.html#pre-and-post-render. You can also leverage quarto run and a Makefile if you don't want the tests to be run at every render. Finally, you might want to run quarto inspect in your project, look at the JSON output, and consider incorporating it into your test suite: it has a number of useful things.

[JosephBARBIERDARNAL]

The pre-render is exactly what I had in mind! Thanks also for the other information. I think I've got everything I need now.

[roaldarbol]

In relation to this, I'm wondering whether it's possible to supply front-matter values from the CLI? That way, especially for template testing, it would be much easier to test each parameter (whether it's missing, correct type, etc.). To me it seems the alternative is to create a bunch of files and run them which seems like a lot more overhead.

[mcanouil]

Anyhow, I agree that the information from the log is confusing.

[roaldarbol]

Would there be a way to provide a nested metadata field? E.g.

group:
	test: "Text"

I tried with -M group.test:"Other text", but that didn't work for me.

[mcanouil]

See #12313 (reply in thread)
--metadata does not support nested field. A YAML file does.

[roaldarbol]

Ah fair enough, thanks for the swift reply.

That would be useful though. For going through all metadata parameters, it's a bit much needing to have a YAML file for each parameter. E.g. wanting to simply test whether the following parameter works as expected when being (1) correct type, (2) the wrong type, (3) is empty.

parts:
  data-availability:
  funding:
  ethics:
  ...

Having to have 3 (or more) YAML files per parameter to do these tests racks up quite quickly.

[mcanouil]

Nothing forbid you to generate the YAML files as I do in the example I shared.