# \#\[test\] and external test harnesses

**URL:** <https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145>\
**Category:** language design\
**Created:** [February 2, 2016, 8:36pm UTC](https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145 "2016-02-02T20:36:13Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![brson](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/brson/32/5197_2.png) [@brson](https://internals.rust-lang.org/u/brson)\
**Post date:** [February 4, 2016, 1:08am UTC](https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145/7 "2016-02-04T01:08:05Z")

</div>

An important requirement for me that I rarely see mentioned is that I need to be able to decouple the test running from the test generation, for example I want to be able to run tests written in any Rust test framework in a Visual Studio GUI.

In this respect I like the internal design of Rust’s test framework - it is just a list of functions to run with some metadata about what the outcome is expected to be. If other test frameworks can compile down to a list of functions that makes the interface to the test runner very simple (e.g. we don’t have to define any specific setup/teardown interface if the frameworks can bake them into the test cases they generate).

Edit: I’m also less enthusiastic than @alexcrichton about adding implicit crate dependencies based on Cargo.toml.

---

_[View the full topic](https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145)._