Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thoughts on colorful test output #255

Closed
softprops opened this issue Jul 26, 2017 · 13 comments
Closed

thoughts on colorful test output #255

softprops opened this issue Jul 26, 2017 · 13 comments

Comments

@softprops
Copy link
Contributor

softprops commented Jul 26, 2017

At the moment it seems likely any streamed test output is hardcoded to suppress color ( -W means without color according to the Runner docs ). For engineers that are coming from sbt and onto baze, color is something that is missed. It also holds practical value to have test failures visually jump out at you in red. What are your thoughts on a patch that would make color and option available to end users?

@johnynek
Copy link
Member

johnynek commented Jul 26, 2017 via email

@softprops
Copy link
Contributor Author

Good to hear. I was just taking the temperature before I sketched out a branch. I may not get to this immediately but will likely circle back at some point.

@ittaiz
Copy link
Member

ittaiz commented Jul 26, 2017 via email

@softprops
Copy link
Contributor Author

I think the two, or three different test runners can work this in as separate efforts for the different rule interfaces. We mainly only use scala_test so that's the one I'd likely be targeting. Our engineers really like its colored output in sbt and we're trying to make the transition a pleasant one.

@softprops
Copy link
Contributor Author

I've got a branch for this but am unsure what a good test for this looks like. would it be okay for open a prelim or to get some initial feedback on what a test might look like?

@ittaiz
Copy link
Member

ittaiz commented Aug 26, 2017 via email

@softprops
Copy link
Contributor Author

Rendered #268

@johnynek
Copy link
Member

@ittaiz I'm not a big fan of big diffs. Can we possibly factor your big diff into chunks each <= 400 lines ideally? In my experience, review quality goes way down on big PRs and sunk cost fallacy starts to build pressure to just merge what is on hand.

@ittaiz
Copy link
Member

ittaiz commented Aug 28, 2017 via email

@softprops
Copy link
Contributor Author

Just looking to guesstimate if I can factor in a upgrade of rules scala in an upcoming sprint at work. For this particular change, it's pretty small but wasn't sure what good tests would look like. I'm happy to wait on a larger pull to make its way through but do we have an eta on when that would happen? On my end, my work task just looks like "improve the bazel testing experience". I think I can accomplish alot with few lines of change but I want to stick as close to head of rules scala as I can.

@ittaiz
Copy link
Member

ittaiz commented Aug 28, 2017 via email

@johnynek
Copy link
Member

johnynek commented Sep 2, 2017

Can we close this out now?

@softprops
Copy link
Contributor Author

Case closed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants