Accueil > professional > How to do UI test ?

How to do UI test ?

Me again…

Well, I just wanted to speak about an issue for which I didn’t find any proper answer yet.

The matter is gui testing. Currently, at work, we do proper unit test for « framework level code ». By « framework code », I mean code being in some utilities or services projects which are put there to be reused. These tests are usually fairly easy to do, since the context is well known. Furthermore, as once as we change this code, these tests prove their value. As changes are made quite often, be it only when adding new stuff and thus refactoring, we feel like these tests are good bang for bucks.

For example, recently, we saw a bug in some on « framework code ». We wrote a failing test for it (well, I’m not 100% sure of that, but we should have had anyway ;)), fixed it and, on the go, spotted some possible improvements. We did them as well, then ran again all tests and we were pretty confident about it.

But, then, what about « project specific code » ?

Hum, what’s in it anyway ? Some « framework level code », for sure, which is already tested, and then some JPA, wicket and business related code. Testing the JPA code would basically mean testing the JPA layer, which is pointless. What about the GUI then ? Well, wicket isn’t exactly the easiest framework for it… The way its generates the ids make it hard(er) for most of the html test tools, like for example selenium. And even if, what to test actually ? Should we do some « clicks through » tests for all use cases ? All possible navigation paths ? And what about the data needed by these tests ? Using WicketTester, then we would be at pain with jquery heavy pages (well, I guess most of the selenium like frameworks are at pain in this case…). Overall, the efforts to put there are likely to be important.

So, what about the gain ? The odds that we’ll touch again these classes are quite low, way lower than framework level code. Basically, we don’t reuse these stuff. And if some functionalities/pages are fine enough, then we may even not touch them again before very long.

In the end, we have some layers which are, at the same time, harder to test and with less « return on investment ». It looks like not testing these « project specific/gui layers » is a good idea…

However, which bugs the end users, tester or product owner are likely to see the first ? The gui bugs, for sure. Worse, whereas framework layer code tends to be mostly Java, the front end relies heavily on nice stuff like CSS, html and javascript. And as if refactoring wasn’t already hard enough there, Wicket, with its string based property and compound models, makes it even harder. So in the end, this gui layer is quite error prone and highly visible to the « customers/users »… Bad isn’t it ? And don’t forget all these quirks about back button, interruption of page loading, browsers inconsistencies and many ui possibilities… Even worse !

That’s where my issue with ui test lies… This ui layer is a pain to test, and would be tested mainly for just a development, without much reuse. But, it’s an error prone layer. And it’s the most visible one… So, if, like me, you’re kind of fond of tests and bullet proof code, then you might well share my dilemma…

What to do then ? Well, for the time, I’ve no proper answer. I guess I should try to spend more time testing my ui before giving it to the outer world, even it feels awkward to do it manually. For sure, exploratory tests might help, but again they’re manual and in no way comprehensive… No clear solution here for me, unfortunately…

Any hint deeply welcome ! In fact, I guess that’s the (hidden) aim of this post : maybe someone’ll come with some magic bullet(s). After all, Christmas is coming soon, so it’s dreaming time anyway 😉

++

Publicités
Étiquettes : , , , ,
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :