You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 29, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 29, 2021. It is now read-only.
I'm curious, what do you see needing done before moving this to 1.0? While I should get back to my regularly schedule project, I would like to also help work towards more crates hitting 1.0.
Good question! I'd like to make the arg parsing a bit leaner (cf. #25 and #32) and maybe improve the error output (#17, #18, #30).
My general goal is to make a library that makes writing tests like these easy and fun. It'll probably involve generating some test boilerplate code, and I'm not entirely sure what I want that API to look like. I'm not even sure if that's in scope for assert_cli. What do you think?
About future ideas, I have been wondering how feasible it is to test for colored output? If my CLI binary prints out colored text, can I test this?
Most programs detect if they are outputting to a console and don't print color if they are. Some have a "force color" option.
So either we'd need to figure out how to fake being a console or clients need to have a force color option and set it.
When forced, I assume color just shows up in stdout as weird characters. Can you just manually enter those characters in to test it? Do you have a proposal for what an API might look like for more advanced color testing?
We've started the major shift to assert_cli 1.0. assert_cmd is the spiritual successor to what assert_cli today. We plan to turn assert_cli into a higher level CLI testing crate like waltz tests.
Activity
epage commentedon Sep 27, 2017
killercup commentedon Sep 27, 2017
killercup commentedon Sep 27, 2017
Pinging some people who used assert_cli in their projects (found using Github search):
We are thinking about doing a 1.0 release and would love to hear your opinion on the crate and ideas for its future!
mattgathu commentedon Oct 1, 2017
mattgathu commentedon Oct 1, 2017
About future ideas, I have been wondering how feasible it is to test for colored output?
If my CLI binary prints out colored text, can I test this?
What are your thoughts on this.
epage commentedon Oct 2, 2017
epage commentedon Oct 2, 2017
Most programs detect if they are outputting to a console and don't print color if they are. Some have a "force color" option.
So either we'd need to figure out how to fake being a console or clients need to have a force color option and set it.
When forced, I assume color just shows up in
stdoutas weird characters. Can you just manually enter those characters in to test it? Do you have a proposal for what an API might look like for more advanced color testing?epage commentedon Oct 12, 2017
killercup commentedon Oct 12, 2017
Freyskeyd commentedon Oct 12, 2017
epage commentedon Oct 12, 2017
Freyskeyd commentedon Oct 12, 2017
epage commentedon Oct 26, 2017
epage commentedon Oct 26, 2017
killercup commentedon Oct 26, 2017
epage commentedon Oct 26, 2017
epage commentedon Oct 27, 2017
epage commentedon May 29, 2018
We've started the major shift to assert_cli 1.0. assert_cmd is the spiritual successor to what assert_cli today. We plan to turn assert_cli into a higher level CLI testing crate like waltz tests.
The building blocks for assert_cli 1.0 are
The bad: it will probably take longer to stablize assert_cli because we need to re-evaluate the design and play with ideas
The good: the smaller pieces should be a lot easier to stablize.
epage commentedon May 31, 2018
Started looking at how others test CLIs and for python, I only found https://bitheap.org/cram/
tests: use assert_cmd and predicates instead of assert_cli
[-]Version 1.0[/-][+]Future of assert_cli[/+]