We are building a new experience for our SmartBear Community.
This site is now read-only. You can still browse and search as usual. Learn More
This site is now read-only. You can still browse and search as usual. Learn More
Hello everyone,
I have started using variables in my test checkpoints, and I have run into the following problem, the solving of which I would really appreciate.
I am testing to see whether the text on an element of one page is the same as the text of the element of another page with the following generalized process:
Pretty simple. However, even when the text is the same on both obj.source and obj.match, the test will still fail, because of the newline character. See the following checkpoint report:
obj.match.contentText (Actual value) vs. obj.source.contentText (Expected value)There is an unexpected turn, however. The following process yields a successful checkpoint with matching values:
Again, this yields a success, and it is because now the obj.source.contentText contains the newline characters, in the form of '/n's
The DevValue variable, which should be the contentText of obj.source and the second checkpoint, which is the contentText of obj.source.I can provide more pictures if necessary. This one has really stumped me.
Thanks a lot!
From my experience when \n exist in your text to move around as you are doing, you face restrictions as you experience.
A suggestion, in your case would it be possible to use two variables?
Read from page A element and save to variable A.
Read from page B element and save to variable B.
Compare variable A with Variable B.
Hope that helps.
From my experience when \n exist in your text to move around as you are doing, you face restrictions as you experience.
A suggestion, in your case would it be possible to use two variables?
Read from page A element and save to variable A.
Read from page B element and save to variable B.
Compare variable A with Variable B.
Hope that helps.
Wow, thank you! It worked!
Use the following: \r for carriage return and \n for new line, within a string.
You have to use backslash and not forward-slash, and also check for space characters too.
Before comparing the strings you could also strip out the offending new line/carriage return characters with aqString.Replace. Just replace them with "".
https://support.smartbear.com/testcomplete/docs/reference/program-objects/aqstring/replace.html
You can further normalize the strings with aqString.Trim. It will remove spaces and control characters for you.
https://support.smartbear.com/testcomplete/docs/reference/program-objects/aqstring/trim.html
Thanks for your advice!
Because the above solution is working I'm gonna refrain from adding code snippets to the Keyword test, but I'll keep that in mind in case I need it for something similar later. The new line/carriage return chars are not important for what we're testing.
Right now my problem is not in anything I am actually typing out. It is that the value stored into my String Variable 'DevValue' (the contentText of obj.source) is not equal to the value that is captured if I just create a checkpoint (for the contentText of obj.source) using the Operations tab.
The \n and other marks are added automatically when the object is selected to create a checkpoint, but they disappear when set them to a String Variable.
TC is only doing what you instruct it, to do. You have to check and verify the contents are captured correctly, in order to perform the comparison. Also, ensure that your variable is not modified afterwards.
Your approach is correct, and it's what I use all the time when scripting.
Here's a simple example,
Keyword stepsOutput results