asterisks displaying instead of single quotes in Command Log assertion
See original GitHub issueCurrent behavior:
Command Log for assertion chain includes confusing asterisks. I suspect it may be replacing \n
with **
.
Even displays in passing tests
Desired behavior:
Error in Command Log should display as:
expected '<div.duration>' to have text '37:46', but the text was ' 37:46 '
Code to reproduce
cy.get(".duration").should("include.text", "37:46")
- Cypress Version: 2.0.3
- Browser Version: Crome
Issue Analytics
- State:
- Created 6 years ago
- Comments:8 (3 by maintainers)
Top Results From Across the Web
Why does bash script add single quotes to string with asterisk?
No quotes are added to the argument; they are just for display purposes. The correct command is egrep "$1" /usr/lusers/me/test/*.test.txt ...
Read more >Command syntax - IBM
Use asterisks to indicate generic specifications of parameters in the SELECT ... Single quotation marks are not valid for symbolic substitution in a...
Read more >Bash Reference Manual - GNU.org
Breaks the input into words and operators, obeying the quoting rules described in Quoting. These tokens are separated by metacharacters . Alias ...
Read more >tsm configuration set Options - Tableau Help
Below is a list of configuration options or keys that you can set with the tsm configuration set command. In many cases you...
Read more >Python Command Line Arguments
Note that surrounding the multi-word string "Real Python" with quotes ensures that the interpreter handles it as a unique argument, instead of two...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi, I’m new to contributing, but I don’t think the problem is specifically due to newlines. It’s the fact that the entire string itself is being processed as markdown. I don’t think that’s a good idea.
In this specific case, the issue is that markdown treats
'** 37:46 **'
as ** 37:46 **, not ’ 37:46 ’ It’s because in markdown, you can’t put a bold tag in front of white space.However, this issue goes deeper than this.
Let’s say I’m looking to match
_37:46_
:cy.get(".duration").should("include.text", "_37:46_")
Now we have italicized our test
Let’s take it to the extreme, let’s say we do this:
cy.get(".duration").should("include.text", "![cypress](https://www.cypress.io/img/logo-dark.4e8064a6.png)")
We get this:
Basically, if your tests include anything that can be parsed by markdown, it will. I have not looked at where specifically in the code these strings are being processed by markdown, but I think it should be avoided (or at least the contents of these strings should not be parsed at all).
Here’s another example of how this could be really confusing:
Let’s look for
*37:46*
:cy.get(".duration").should("include.text", "*37:46*")
Now we get this:
This makes no sense at all since it’s saying that two identical strings don’t match. It should show exactly what it does further down:
My conclusion would be that these strings shouldn’t be parsed by markdown at all. It would also make sense to add quotes so that it would be more obvious why the two strings don’t match.
I’d be happy to investigate the code and make these changes, but I’d imagine a design change like this would have to be signed off by someone.
Released in
3.7.0
.