# Writing tests for @compileError **URL:** \ **Category:** Help\ **Tags:** language, compiler\ **Created:** [December 17, 2025, 1:54am UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540 "2025-12-17T01:54:34Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ww520](https://ziggit.dev/letter_avatar_proxy/v4/letter/w/c2a13f/32.png) [@ww520](https://ziggit.dev/u/ww520)\ **Post date:** [December 17, 2025, 1:54am UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540/1 "2025-12-17T01:54:34Z")
I have used @compileError for doing validations during compilation, basically to catch errors early on. What’s a good approach to test those validations? Currently I put in the calls that would trigger the @compileError in tests, and test them by doing manual compilation. Then comment them out afterward, with a note left behind saying to uncomment this to test such and such @compileError. ---
**Author:** ![ForeverZer0](https://ziggit.dev/user_avatar/ziggit.dev/foreverzer0/32/2443_2.png) [@ForeverZer0](https://ziggit.dev/u/ForeverZer0)\ **Post date:** [December 17, 2025, 2:55am UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540/2 "2025-12-17T02:55:42Z")
Frankly, I think the test case is when it fails to compile. While I am confident there are many other use-cases for it beyond validation of types (i.e. `anytype` that would often cause a complication error down the road anyways) , I mainly use it as a means of providing a helpful error message at the error location instead of some other nebulous compilation error later on with a less helpful message. So instead of a message about a struct not supporting an addition operator in some random function, a consumer gets a message explicitly stating a signed integer or float is required _here_. I don’t know if “testing” them really makes a lot of sense within the context of their purpose. i do agree that their could be some cases where it would be helpful, but it is beyond my reasoning how it would even be possible to test such a thing. ---
**Author:** ![ww520](https://ziggit.dev/letter_avatar_proxy/v4/letter/w/c2a13f/32.png) [@ww520](https://ziggit.dev/u/ww520)\ **Post date:** [December 17, 2025, 3:36am UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540/3 "2025-12-17T03:36:25Z")
Point taken. In my case, I’m writing a library and want to make sure the user of the library is using it correctly. Some of the validations are @compileError checks. They become part of the UX of the library. It would be nice to add them to the tests. ---
**Author:** ![npc1054657282](https://ziggit.dev/user_avatar/ziggit.dev/npc1054657282/32/5790_2.png) [@npc1054657282](https://ziggit.dev/u/npc1054657282)\ **Post date:** [December 17, 2025, 6:30am UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540/4 "2025-12-17T06:30:22Z")
> > > Minor feature to test edge cases. > > Zig allows custom made compiler errors. Ex…ample is here: > http://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html > > There should be some easy way to check if they are implemented correctly. > > \---------- > > My proposal: > > \`\`\` > test "expected to fail" > { > something\_generating\_error(); /// DOES NOT COMPILE > } > \`\`\` > > If compiler reaches \`@compileError\` inside a test it should then look for comment \`DOES NOT COMPILE\` at the offending line. If it finds it there, all is OK, testing continues. If it doesn't, original error is reported, it is a bug to be fixed. > > If the test compiles OK but contains \`DOES NOT COMPILE\` comment, then it should fail. > > \--------- > > Alternative is special keyword for failing test, but this feels as overkill. > > Feature should be limited to user written \`@compileError\` only: syntactic errors (like unbalanced parenthesis) should be always error, wrong use of the language (\`x = 1 + "abc"\`) as well. > > \`DOES NOT COMPILE\` comment outside a test means nothing. > > Expected failed test would generate no code. > > Failing tests could be certainly implemented as separately compiled files, but this is nuisance most people would avoid. It is a accepted proposal. ---
**Author:** ![ww520](https://ziggit.dev/letter_avatar_proxy/v4/letter/w/c2a13f/32.png) [@ww520](https://ziggit.dev/u/ww520)\ **Post date:** [December 17, 2025, 6:35am UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540/5 "2025-12-17T06:35:09Z")
Good to know it’s in the pipeline. ---
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [December 17, 2025, 1:26pm UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540/6 "2025-12-17T13:26:55Z")
You can pull off this kind of testing without any help from the language. With the Zig build system you can expect a given step to fail and you can capture its stdout/stderr output and compare it against a known good value. As a similar example, this is how I do snapshot testing with Zine: [zine/build.zig at 03734aa552eba662db4d4d166a4220b132b302f9 · kristoff-it/zine · GitHub](https://github.com/kristoff-it/zine/blob/03734aa552eba662db4d4d166a4220b132b302f9/build.zig#L350-L354) In your case you would want to invoke the Zig compiler itself, ask it to build a test project (if the code that you want to test is dependency free, you can even just `zig build-exe` a single file) and then expect that build to fail in the build system. Coincidentally, this is also how some Zig compiler tests work. Related post: [Dead Simple Snapshot Testing In Zig | Loris Cro's Blog](https://kristoff.it/blog/dead-simple-snapshot-testing/) ---
**Author:** ![ww520](https://ziggit.dev/letter_avatar_proxy/v4/letter/w/c2a13f/32.png) [@ww520](https://ziggit.dev/u/ww520)\ **Post date:** [December 17, 2025, 4:02pm UTC](https://ziggit.dev/t/writing-tests-for-compileerror/13540/7 "2025-12-17T16:02:44Z")
Doing it at the build process would work. Thanks!