Comments (6)
The reason for having them in tests
is so that they get built and run automatically with cargo test
but I will look into moving them to examples as you are right that they should really be there!
from combine.
Oh yeah, didn't see test/
^^. I was talking about the examples in the doc.
from combine.
Aha, well I don't know what benefit there is to copy them to examples
. I guess they could print out they result in (what they assert on)? Otherwise running them would not do anything that cargo test test_name
does now?
from combine.
cargo run --example
, with a println!
of the result, I think. It's a standard directory, so people automatically go see what's in it if they want examples.
from combine.
You can add to Cargo.toml to run it automatically.
Cargo guide:
cargo test runs additional checks as well. For example, it will compile any examples you’ve included and will also test the examples in your documentation. Please see the testing guide in the Rust documentation for more details.
(I'm on mobile, sorry for the link)
And assert_eq! works fine with it. Test fails when assertion in example failed
from combine.
@kdy1997 That is only when running the examples manually. Just running cargo test
only builds the examples and does not run them.
I think the way to fix this properly though is to have the examples in examples/ directory and then also have separate tests which runs the example executable, feeding it input to its stdin and reading its stdout to compare with the expected result. Did that for gluon-lang/gluon#226 (though it reads/writes to tcp stream).
from combine.
Related Issues (20)
- Publishing 4.6.1? HOT 1
- choice! returns an error when one of its parsers would be successful HOT 2
- Throw stream errors HOT 5
- DateTime parser HOT 1
- take_until_bytes() and partial parsing HOT 2
- Is there a way to get `Stream<Token=char>` from `io::Read`? HOT 1
- Tools for debugging recursion problems? HOT 4
- Some issue with error reporting
- Errors include unprintable or awkwardly printed characters. HOT 6
- `expected` error strings always quote what was expected, even if it isn't a literal HOT 3
- How about offset into some data? HOT 3
- Outdated tutorial HOT 1
- Native/abstracted sub-parsers HOT 6
- XML parsing for React.js to Solid.js conversion HOT 4
- Comparison with LALRPOP
- Unbounded mutual recursion in Parser impl HOT 3
- Adivce on reducing code size in WASM target HOT 7
- Docs unclear whether `parser!` should be used on nightly rust HOT 2
- Parse `std::process::Child` stdout
- Successful parser will not clear the error stack HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from combine.