<div dir="ltr">On 13 March 2014 14:20, Sai Vineet <span dir="ltr"><<a href="mailto:saivineet89@gmail.com" target="_blank">saivineet89@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Question: is there no other way to write UI tests? ATK is a pain.</p></blockquote><div>You need some kind of out-of-process mechanism to click around, "see" the UI etc. I'm not sure there is anything better than atk for that.<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"> And if I'm not wrong ATK is a accessibility related thing, so we're using the using the wrong way to test?<br>
</p></blockquote><div><br></div><div>Well, dogtail, which is far as I know is the only alive test automation framework for gtk, uses ATK in the same way. Also using the accessibility toolkit for UI test is something seen in several other toolkits. You need the same kind of things...<br>
<br></div><div>I'm not sure what is you issue with ATK exactly. The current sugar.test.uitree stuff is really low level, you could build something more friendly on it perhaps (or use dogtail even, I gave up on it because it was too complicated and racy but things might have improved now that ATK is more stable). But there might also be an issue with the amount of information ATK exposes, some of our controls doesn't quite show up in the tree I think. Though that might also be fixable, by improving our accessibility story at the same time :)<br>
</div></div></div></div>