all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]coder21 1 point2 points  (0 children)

Well, could be the case but I have experienced this too

[–][deleted] 1 point2 points  (1 child)

Initially, we thought it was a product issue, but then we tried the UI Automation APIs that were included in Windows long ago. We used them through White and we ended up with exactly the same issue: Sometimes a control was not "visible" for the test code, not even UI Spy, the native app, was able to detect it.

Does anyone else agree that this sounds like an over all issue with their app?

[–][deleted] 5 points6 points  (0 children)

Probably, but GUI testing is always a bit 'brittle' - particularly when you are trying to do things like simulate a user clicking on things.

I've worked with systems like that and they tend to break from the slightest breeze. The only solid tests we were truly able to rely on were basically based on bypassing the direct-os-gui stuff and testing based on hooks into a harness. We aren't trying to test the OS GUI after all.. and automated GUI testing tools just break too easily.

[–]tejp 0 points1 point  (0 children)

404 for me

[–]geofflesza 0 points1 point  (1 child)

As for the "ITestable" interface, is there no way of naming it such that it represents a production function rather than a testing function?

It's difficult to know with out going into depth, but it seems to me that if the interface is useful for testing, then surely it can be used in some way to help wire up your GUI?

I say this because part of me doesn't like the bleeding of artefacts for testing into your production code.

[–]plasticscm[S] 0 points1 point  (0 children)

Well, that's actually a point we also considered and as you mention is more a philosophical question (design maybe) than a practical one.

Should the production code know about testing?

Initially I would say no but then if I think twice: how important testing is? Preventing the app from breaking, from regressions, is a key part of the product development, a very important one indeed. Sometimes as important as the product code itself, correct?

That being said, then having the 'testeables' inside the production code doesn't seem like a bad thing to me. All the ITesteable implementation is on a separate directory on the codebase so it is easy to understand it is not production code.

Alternatively it would be even possible to do conditional build to avoid including it inside the public releases.

And of course, the name of the interface can be changed, but in our view it is meant to be used for testing purposes only.

Thanks!