关于对包含多个子元素的元素的text断言支持不完善的问题

[stevobm]

测试的时候我们经常遇到一个场景，那就是要对一个列表进行整体断言，判断结果是否符合期望。最简单的方法是直接对列表项的父元素(即列表本身)进行text断言，这样就可以对比到所有的列表项了。

但是通过一段时间的使用发现，uirecorder对包含多个dom元素的父元素的text断言支持并不是特别好。具体表现为：

1.uirecorder对包含多个子元素的元素进行text断言时，输入框中生成的内容有很多空行和空白字符，而实际断言结果其实去除了多余的空白字符和空行（规则还未完全弄清楚），最终导致断言结果不匹配；

2.当列表中包含隐藏元素时，输入框中生成的内容为包含隐藏元素文字的，而实际断言结果其实是不包含隐藏元素的，这也会导致最终断言不通过。

以上两个问题一定程度上制约了text断言的适用范围，而text断言本身非常有用，希望这两个问题可以修复，让uirecorder发挥更大的价值，谢谢！

[yaniswang]

出现这个问题的原因是添加断言时设置的默认值，是用JS获取的，而最终断言执行时是用webdriver执行获取的，两边的算法不一致，就会出现断言复杂DOM时，结果不一定一致。

研究下webdriver的text算法，两边保持一致，就可以解决这个问题了。

[yaniswang]

https://chromium.googlesource.com/chromium/chromium/+/master/third_party/webdriver/atoms.cc

晕菜了，算法完全看不懂，而且也太长了……

[stevobm]

这js都压缩了呀。。没有诚意。。

[yaniswang]

这个问题暂时无解，录制时提供的默认断言目标值目前来看，还暂时只能仅供参考，没办法作为准确的断言目标值。

可以跑一次，看看断言失败的提示，把正确的值复制到代码中，再跑一次就正确了。

目前只能这么搞，或者你一起帮忙想想，看看有没有别的什么好的解决方案。

[stevobm]

这个文件是自动生成的，我感觉是不是应该找一下js的源代码

[stevobm]

对了，我们不是有同步浏览器吗？可不可以直接拿同步浏览器取值的结果作为推荐值？

[yaniswang]

这个方案当初想过，但是由于来回周期太长，整个方案会比较复杂。

[stevobm]

chromedriver的那个代码应该是故意混淆了的，直接逆向貌似不太可能，而源代码本身的处理逻辑可能并不复杂。 目前经过我多次的测试和观察，主要就是换行处理和元素隐藏存在差别，其他的好像也看不出来。如果我们能够解决这两个差别并实现大部分场景的text断言都能够匹配，这个地方应该就不是问题了。

[yaniswang]

这个问题暂时只能这样了，显示出来的文本仅作为参考，除非能实现chromedriver内部一模一样的算法

[stevobm]

我做了大量试验，发现如果做到两点，那么我们的断言就可以跟chromedriver完全一致：

1. 取元素的时候先去掉里面包含的隐藏元素，chromedriver的text断言里面是不包含隐藏元素的文本内容的；
2. 界面上的格式可以按照目前的来显示，但是后台实际对比的时候忽略空白字符(两边的内容都先去掉所有空白字符再对比)。因为有的时候chromedriver的text断言里面会有空格而我们直接取text()却没有，这样很难反向加上，所以还不如都去除空白再对比，这样就可以保证一定成功，text断言才能在广泛的测试场景中起到实际意义。