Merge pull request rust-lang#13 from Centril/roadmap-2018-patch-testing

Boost focus on testing

text/0000-roadmap-2018.md

@@ -57,6 +57,8 @@ To make our product successful, we should build and market it with an eye toward
 - **CLI apps**. A place where Rust’s portability, reliability, and ergonomics come together to great effect.
 - **Embedded** **devices**. A domain with a great deal of potential that is not yet first-class.
 
+To gain confidence in ecosystem quality and reliability, we will also focus on providing great **testing libraries** with which crates in these four domains can be tested.
+
 Looking at the year as a whole, with our second marketing release of Rust, @nrc perhaps put it best:
 
 
@@ -147,12 +149,13 @@ Compiler work will center on:
 
 > [The core team should participate in prioritizing and implementing quality crates for productivity needs.](https://medium.com/@nimtiazm/rust-and-crate-of-wishes-for-2018-1258f6977d42) (@nimtiazm)
 
-In preparation for the epoch release, we will continue to invest in Rust’s library ecosystem in three ways:
+In preparation for the epoch release, we will continue to invest in Rust’s library ecosystem in four ways:
 
 
 - **Quality**. Building on our 2017 work, we will bring the API Guidelines to a 1.0 status and build out additional resources to aid library authors.
 - **Discoverability**. We will continue to work with the crates.io team on discoverability improvements, as well as push the Cookbook (or something like it) to 1.0 status as a means of discovering libraries.
 - **Domain-specific content**. We will work with library authors in the four domains of focus this year to sharpen our offerings in each domain (elaborated more below).
+- **Testing**. To ensure the quality of these offerings, we will also work with authors of testing libraries to make testing easy and more widely used. A working group for testing, reporting to the core team, will be formed to consolidate efforts and strive for better integration.
 
 #### Documentation
 
@@ -185,7 +188,7 @@ Beyond these clear-cut items, there are a number of ongoing efforts, some of whi
 
 And a couple of goals that are probably a stretch for 2018 at all, let alone for the epoch release:
 
-- **Custom test frameworks**. There’s been [a lot of interest in this area](https://internals.rust-lang.org/t/past-present-and-future-for-rust-testing/6354/1), and it may be possible that with a dedicated working group we can implement and stabilize test frameworks in 2018.
+- **Custom test frameworks**. There’s been [a lot of interest in this area](https://internals.rust-lang.org/t/past-present-and-future-for-rust-testing/6354/1), and it may be possible that with a dedicated working group we can implement and stabilize test frameworks in 2018. If not, custom test frameworks should at least be available as an unstable feature and a merged eRFC, such as [RFC 2318](https://github.com/rust-lang/rfcs/pull/2318), with which we may gain confidence.
 - **Compiler-driven code completion for the RLS**. Today the RLS still uses a purely heuristic approach for auto-completion. If the compiler’s new “query-based” architecture can be pushed far enough during the year, it maybe become feasible to start using it to deliver precise auto-complete information.
 
 #### Web site