Radiobutton #1 (which is visible) has Width property == 113
Radiobutton #2 (which is invisible) has Width property == 107
Why so?
I gave same question before to dev - "if u have that property diffrent please check if any other properties are diffrent"
He said that the only diffrence is:
a) width - dosent matter for TC for sure.
b) sorting objects - (prolly matter for control index in TC) - I think it dosent matter if i click objects in my tests by fullname not by index.
Couple of things:
1) It sounds like you actually, in that 20% of cases, have two components on the form... one visible, one not... the invisible one is, for some reason, overlapping your visible one so that, when you use ObjectSpy, it only sees the invisible one. Something to check. In TestComplete, go to the object browser and go to your form when you are in one of those 20% situations and check the list of objects. If you see two sets of radiobutton groups, one visible, one invisible, right there is the proof because...
2) Even though it's not a problem for the end user, this is, in my opinion, bad code. You have memory being taken up by something that is not being used. Who knows what effect will happen later on down the road? And if they are doing this regularly, that means that the memory usage of the application is higher than it should be. The memory is not optimized... which is, therefore, a bug, especially if it is something that was introduced by development.
3) AND if they do have two different radio groups for, effectively, the SAME FUNCTION (selecting gender in your example)... um... what is with that? That's bad coding practice no matter who you ask. You never make NEW code (in this case a component on a form) when there is code that can be reused for the same purpose. So... again, no "bug" with regards to the end user, but now you've introduced a problem where if they need to change the logic behind the radio button, they could, potentially, change it for one component but "forget" to change it for the other, introducing a NEW bug of inconsistent functionality... all because they didn't create the UI properly. Sure, the end user may not experience a problem, but if you can prevent problems down the road, so much the better.
These are arguments that you can take to your developers as impetus to fix the problem. Additionally, you are, as a tester/QA person, a "customer" to the developers. You can't use the application as it is. Therefore, you have a bug that they need to fix.
"2) Even though it's not a problem for the end user, this is, in my opinion, bad code. You have memory being taken up by something that is not being used. Who knows what effect will happen later on down the road? And if they are doing this regularly, that means that the memory usage of the application is higher than it should be. The memory is not optimized... which is, therefore, a bug, especially if it is something that was introduced by development."
As tristaanogre says, I hit exactly this scenario with my Delphi application. Invisible, now unused, objects being left behind in the object model. In effect, a memory leak. Exactly as he says.
I raised it as a bug. It was treated as a bug. it was fixed.
End user would never have noticed (was never likely to be a leak of problem causing scale). It had probably been like that for years (this software is pretty mature!). No matter. Still a bug. Still needed fixed.
escap89 wrote:He said that the only diffrence is:
a) width - dosent matter for TC for sure.
b) sorting objects - (prolly matter for control index in TC)
I believe that is bad design. If gui elements are the same, they should have the same properties. Otherwise they are differ. My suggestion - that something overlaps your radiobutton and makes it invisible (for TC). 1 pixel is enough to do so.
