Piotr Woloszyn

I came across a strange behaviour of Selenium and wanted to share my pain with someone really. But first couple of words of introduction. I use Selenium in my current webapp project which I am working on. The application uses quite a lot of javascript (Dojo framework mostly) which can be tested using D.O.H. framework but the Selenium is giving us the final sanity checks, acts as integration test framework and may be used by product owner in an agile environment to drive acceptance on user stories via automated acceptance tests.

Selenium is an excellent package. I really love it. Just to mention integration with various browsers, Selenium IDE, support for integration with build (Selenese ant task) and really easy way of creating and storing the tests as HTML. It is a framework which cannot be ignored by anyone working on webinterfaces.

There is previously mentioned selenese ant task which helps with integration of the Selenium tests and an ant build. You can grab the jar from the Selenium RC distribution.

However as most of the things around us it is not a perfect software. Anyone had the famous “Permission denied to get property Location.href”? Cross domain scripting issues?
In my case I figure out two reasons for above problem and I wanted to share it:

Problem 1:

Let’s look at the following selenium command:

• open
• http://host/some/url

Looks good, doesn’t it? So it might work, but it can as well break on another box with the “Permission denied to get property” and some other scary warnings. The solution in this case was simply to remove the host definition from url leaving just:

• open
• /some/url

Problem 2:

One of the pages I was testing had redirection in case of the authorization violation. So esentially after single HTTP request the browser was receiving single response with redirection and then performed another request to the URL defined in the redirection. Selenium couldn’t handle that correctly. But again, it wasn’t deterministic, it could work on one box but fail on another. Timing issues etc. Hate that. Neither of the combinations worked in consistent way: openAndWait, open + pause.

The solution in this case required change in the webapp to remove usage of the redirection (which I believe was an ugly way of dealing with the problem anyway).

Hope it will help someone with similar issues. If you know another tricks or something to avoid when using Selenium please contact me or leave a comment here.

Popularity: 65% [?]

Share This

I believe in testing, I really do. Combined with continuous integration, daily builds and automation of all aspects of build process, those are for me mandatory elements of a software project which has got any aspiration to be a successful one. Joel thinks there are more.

I believe in unit tests as well as integration and acceptance tests. I can see value of that and I use TDD happily for last two years and unit testing without being so strict about that for much longer time. It just works for me, gives me something.

However I still have questions regarding this subject. Let’s just put up first of them:

Should we or shouldn’t we unit test private methods of a class?

There are valid reasons for both of them. From one hand if we limit ourselves to a public interface and we test our class as a black box which behaves in a certain way and we don’t care how it is implemented then the tests are easier (read cheaper) to maintain. Whenever we have to change implementation we don’t have to change tests. Neat.

But there is other side as well. What about this word unit? What about TDD? If TDD can actively help us with process of developing a single unit of code why not to use that? As we all know the first red - last green routine of writing test, making it fail, developing code, making the test pass might be painful, might take long time to switch to that way of development but and the end of the day gives code of the better quality. But now what shall we do if that single unit of code by design is a private method? Shall we change that following philosophy of design for testability? It again might lead to innocent changes like converting (Java):

private void foo() {
...
}


to:

protected void foo() {
...
}

Then we can create unit tests for that method in the same package. It was really innocent. What if we have to reach to a toolbox with dirty tools? We can’t really use the same solution for C#. Let’s first have a look at the method access modifiers for that language:

• public indicates the method is freely accessible inside and outside of the class in which it is defined
• internal means the method is only accessible to types defined in the same assembly
• protected means the method is accessible in the type in which it is defined, and in derived types of that type. This is used to give derived classes access to the methods in their base class
• protected internal means the method is accessible to types defined in the same assembly or to types in a derived assembly
• private methods are only accessible in the class in which they are defined.

As we can see our dear friends from Microsoft have done it in even more problematic way. We have a choice of converting private methods to internal but our tests have to be placed in the same assembly as the production code or we can use the public modifier or we have to use some tricks with reflection. Not perfect, wrong or smells.

I understand that there is no universal answer for the question above. Applying common sense usually pays off but I wonder what is your opinion about testing in general with focus on testing private methods.

Popularity: 27% [?]

Share This