# Why is \`Test\` so meta-programming heavy?

**URL:** <https://discourse.julialang.org/t/why-is-test-so-meta-programming-heavy/94619>\
**Category:** Internals & Design\
**Tags:** testing, design\
**Created:** [February 14, 2023, 11:00am UTC](https://discourse.julialang.org/t/why-is-test-so-meta-programming-heavy/94619 "2023-02-14T11:00:03Z")\
**Posts on this page:** 1\
**Showing post:** 32

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [February 20, 2023, 8:14pm UTC](https://discourse.julialang.org/t/why-is-test-so-meta-programming-heavy/94619/32 "2023-02-20T20:14:33Z")

</div>

> [@nrontsis](#):
>
> lack of debugging

I might be wrong, but I think that would not be easy to pull off in the existing base test framework. I think it would probably be much easier to add debugging support to the [test item framework](https://discourse.julialang.org/t/prerelease-of-new-testing-framework-and-test-run-ui-in-vs-code/86355), in fact pretty much all the pieces need to pull that off inside VS Code exist already. I “just” need to hook it all up 🙂 No promise on when that is going to happen, it is on my roadmap, but it also is probably a pretty significant lift, so it might be a while. But at least the design should really lend itself very well to implementing this.

---

_[View the full topic](https://discourse.julialang.org/t/why-is-test-so-meta-programming-heavy/94619)._
