Unit testing advice

[ron.lawrence]

Hi all,

Does anyone have advice on testing SmartGWT applications? Unfortunately, SOASTA is off the table where I work, given the investment (time and training) they have already made in various other testing tools. I have read here that some selenium support is upcoming, and I will definitely take advantage of that. I have already had limited success in testing using the JavascriptExecutor to directly invoke code in the browser in selenium unit tests, but these are rather complex to set up, and this type of hand written "integration-unit" testing tends to get quite expensive to maintain over time.

I have not seen many other posts here related to pure "unit" testing, so I'm looking for advice on what unit testing framework(s) to use, and how to best organize smartGWT code such that it is easy to test. GWTTestCase seems like a non-starter, but I'd love to hear how to use it in this mix.

Thanks!

[sjivan]

Have you tried using GWTTestCase? If not, please do so and report if you run into any issues.

Sanjiv

[ron.lawrence]

Sanjiv,

Thanks for your reply. I will try it.

I wonder if there are any examples out there of this or other approaches being used with SmartGWT. In the smartgwt LGPL code I don't see any java based unit tests of any sort, so I'm wondering what the best practices here are.

Also, as I investigate my testing options, I keep encountering advice on building GWT apps using Command pattern, MVP and an Event bus. I'm wondering how well this will work in smartGWT, where the widgets are already so tightly coupled with their own architecture for interacting with a model (DataSource). The last thing I want to do is burn time adding a Presenter layer of indirection between the views and their data and discover down the road that they don't buy me any benefit in testability.

See http://www.scribd.com/doc/17474511/GWT-App-Architecture-Best-Practices for example of this sort of advice.

[Isomorphic]

You definitely do not want to head down the road of MVP and re-inventing the built-in functionality. One way to think of it is, that would be an approach for testing code that you do not need to unit test in SmartGWT since it's built into the framework. So just focus on high-level application functionality instead.

[sjivan]

Selenium support has been added to Smart GWT. The user guide and Selenium extensions can be found under the "selenium" subdirectory in the SmartGWT distribution zip file. This will appear in the next nightly build.

Sanjiv

[taxaw]

What A Good News

Nice to hear that selenium is now supported by Smartgwt.
Now i can really use Smartgwt and perhaps SMARTGWTEE.
Thanks a lot.

[jorel]

You definitely do not want to head down the road of MVP and re-inventing the built-in functionality. One way to think of it is, that would be an approach for testing code that you do not need to unit test in SmartGWT since it's built into the framework. So just focus on high-level application functionality instead.

I keep seeing comments and documentation like this that seem to be strongly suggesting that SmartGWT should not be thought of as a set of highly refined widgets (which is what I would like to think), but rather, as a complete application framework that shines your shoes also. Don't get me wrong, I'm very impressed with what has been done. But there seems to be a bit of 'upselling' going on, trying to convince people that they need to purchase the server support version of SmartGWT.

What about us folks that just want to use your amazing widgets within a more loosely coupled architecture because we are convinced by our own experiences and those documented by others that this is the best approach?

I have been evaluating SmartGWT for my company's next project and I must say, it has a lot going for it. The widgets are very good - the best I've seen in the GWT space. But I cannot commit to use something that will not fit into my architectural requirements. I have been burned too many times by spaghetti code that resulted from tightly coupled designs.

Please convince me that I'm wrong!

[Isomorphic]

SmartGWT supplies both widgets and data binding services. The data binding services exist in the free LGPL version and are not an "upsell" - see, for example, RestDataSource. Nor is there tight coupling or any reason to expect you will be writing spaghetti code.

Basically, having construed SmartGWT to be a bunch of widgets, you've missed more than half of the picture, you don't know what the SmartGWT architecture actually is, so you have no basis for comparison with anything else. You should start over.

[mike.art1]

you don't know what the SmartGWT architecture actually is, so you have no basis for comparison with anything else

Without an architecture guide or reference manual how do you expect a person evaluating the framework to know it. Please don't point to the FAQ as its not a substitute for good documentation. Don't get me wrong, you have an amazing framework. Spend some time and put together some documentation.

[Isomorphic]

? Have you read the QuickStart Guide? We haven't finished the dedicated SmartGWT version yet, but in the interim we put together materials explaining what parts apply and how.

This then leads into the data integration overview documents which cover how components issue DataSource requests and what to do with them.

It sounds like you're coming from a recollection of many many months ago when you first started using the framework and many of these materials did not exist. It's gotten a lot better; it's getting better all the time.

Regardless, this particular poster essentially decided that data binding was somehow tied into the server. You can't read the current overview materials and come away with that conclusion.

[dfreire]

Having used Smart GWT for more than a year now, and having tried to fit my application architecture into the MVP pattern using Smart GWT, I can only say, it is possible, but it's a tremendous amount of work.

Now my approach with Smart GWT is don't try to fight it, embrace it instead. If we get used to Smart GWT architecture, we'll be in a much happier path.

The View in the MVP pattern is a dumb class, completely isolated from models and presenters, that renders something into the screen. In Smart GWT we rarely need to create Views ourselves, because we are already using the widgets that come with the framework. We don't need to render anything in the first place.

The Presenter in MVP controls the view according to state. In Smart GWT we do not exactly use these kind of presenters, because, again, the framework already maintains state. But we do need some kind of controllers, to handle events and interactions between components.

The Model in MVP is just data, and in Smart GWT we have data sources.

Smart GWT follows more of a client-side MVC pattern than a MVP pattern. The Views are the widgets, the Models are the data sources and the Controllers are classes we create ourselves to manage views and datasources (but Smart GWT also includes its own built-in controllers, provided to us automatically, think for example of auto-fetch in a data bound component).

Now, I have also found my application code very hard to unit test on the parts that interact with Smart GWT. The problem is, for example, I cannot test a controller that wants to get the selected record of a ListGrid and access to its attributes. The reason is that Smart GWT classes contain native javascript code that binds to SmartClient.

I cannot mock ListGrid or ListGridRecord because they represent native classes, and mocking frameworks cannot mock native classes. The whole thing could be solved if ListGrid and ListGridRecord (and all the others of course) were just interfaces that had implementations in native classes that would bind to SmartClient.

Then we could all just unit test our code with mock implementations and have 100% testable code.

[dfreire]

Actually, after writing the previous post, I searched again for mocking frameworks, and found jmockit: http://code.google.com/p/jmockit/

This mocking framework CAN mock native classes. As well as statics, as well as finals. This is very impressive. I have tried it out in a sample Smart GWT project and the result is: 100% testable code.

These are very good news for Smart GWT users I think :-)

[abhisec]

dfreire you said you made progress with jmockit. can you post some samples?