Selenium xpath - issue locating WebElement using contains(text(), 'somevalue')

I've recently encountered an issue where my xpath should be easily expressed as
xpath=//div[contains(text(), accountId)]
but this did not work. I thought I'd share the problem here.

I am trying to identify

<div class="your-account-info" style="background-color:blue;">

  <span class="hidden">Your account number: </span>

  123456789

</div>

so as xpath of 

//div[contains(text(), '123')]

should work, but doesn't. 

What does work 

<div class="your-account-info" style="background-color:blue;">

  matt was here

  <span class="hidden">Your account number: </span>

  123456789

</div>

using an xpath of 

//div[contains(text(), 'matt')]

will return the object.

Conclusion

So it appears that text() within xpath identification will only get text up until the start of the next tag.. which is limiting.

I am not sure of a workaround yet, but will post one as soon as I've answered it.

Test-creators should maintain

I’ve had the opportunity once to work on a project where test-creation and test-execution were two activities performed by two entirely different teams. Interestingly this produced the problem of considerable test rework being required by the maintenance team on all newly created assets. The problem was that, while the tests were fit for purpose and passed on day 1, there always were enough slightly fragile components which gave newly created asset an embarrassingly short life-span. This was the result of some genuinely overly-complex actions, reliance on particular dates/times, and assumptions about existing data.

For a long time the execution team was responsible for these assets, but it became increasingly obvious that the creation team were not improving on the quality front. If anything they/we were getting worse over time, as we continued to build test upon test using our slightly dodgy implementations.

We ended up changing the ownership of assets by introducing a warranty period. In order for the creation team to appreciate and learn the onus of fixing broken assets remained with the creation team for several months after the script was declared ‘ready’. While productivity took a  hit initially, it wasn’t long before we ended up with considerable time-savings. Knowing what pain was in store resulted in a real shift in culture when creating assets. The amount of code-reuse increased considerably, and the overall maintenance effort decreased. The future tests we created were built with the knowledge of what went wrong previously; that makes for a pretty solid foundation.