As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the best way to test GWT code?
GWTTestCase in hosted mode is too slow and none of the mocking frameworks work.
Currently we are following MVC as suggested in http://robvanmaris.jteam.nl/2008/03/09/test-driven-development-for-gwt-ui-code/ and using GWTMockUtilities disarm() and restore() to mock widgets. And we havent figured out a way to test View in GWT MVC. Is there a better way to test GWT code?
If you're looking to test GWT widgets in isolation, there aren't many options. You can use a GWTTestCase to instantiate your widgets and test it through its API, which is what Google does for the GWT widgets themselves: Source for RadioButtonTest
However, the event-firing mechanism doesn't work in GWTTestCases, which means you can't do things like programmatically click a button and expect some onClick() callback method to be invoked on a listener. It also is hard if not impossible to get at the underlying DOM, so it may not be the best tool for testing low-level HTML-emitting code.
It sounds like you are following all the right steps; Rob's article provides an excellent description of how to write testable code using the Model-View-Presenter (MVP) design pattern. The more logic you keep out of the view layer, the better. When that's not possible, use a tool like Selenium to create focused tests of dynamic UI behavior.
I followed a similar strategy - MVP with minimal code in the widgets. In a few cases I did write some code which would wrap the Grid class, so I was able to instantiate my component in a GWTTestCase, pass it a Grid, invoke some methods on my component, and check the state of the Grid. I wrote an article for Better Software about Test-First GWT, which you can read on my blog.
If you're looking to test code that uses non-UI GWT classes (such as URL encoding or Dictionaries), you'll need to use GWTTestCase, or else follow similar wrapping strategies until the code is too simple to break. Then use an integration test with a tool like Selenium, or a few targeted GWTTestCases which only test that you're using the library correctly -- as J.B. Rainsberger says, "Don't test the framework!"
As an alernative, you should try gwt-test-utils, which manage to run GWT client code in a standalone JVM and provides some feature to Mock anything you want (component, RPC services, etc..)
What worked for me:
Use classical model/view/controller (e.g. no business logic in the view or controller; controllers only translate view events into method calls on the model).
Decouple the model and controller code from the GWT view widgets and any other classes that rely on GWT and can't be instantiated in a plain old JVM. You can then test them with good old JUnit.
Write end-to-end tests to test the system through the GUI to ensure that the models and controllers are hooked up to the views correctly. We found it faster to deploy and start up the app and then interact with it through a browser controlled from JUnit with WebDriver than to use GWTTestCase!
Use JMock to test asynchronous calls like this: http://www.jmock.org/gwt.html.
Also have a read at Testing Methodologies Using Google Web Toolkit
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I used play2 before with java. It felt a little bit like boilerplate especially if you used akka with java. But that is not the fault of the framework.
Yesterday I read "Scala for the impatient" and I really enjoy the language.
Now I looked at both frameworks Lift 2.5 and Play 2.0.3. I think lift has a higher learning curve and I could not just do something with lift. This is not a con for me. From what I saw, Lift has a very nice and clean design.
But for me it is hard to tell what the main differences are. I think both frameworks are great.
The Views First approach doesn't allow you to code in your templates, instead you have to code in snippets. I like this a lot because it looks more organized to me. It also lets you use a normal html editor.
(I have not much experience, this is just my first impression)
For the security I don't think that is the job of the framework.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Both frameworks are able to compile after you press F5. I like this feature a lot.
Both frameworks are using sbt
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has a ORM mapper for mongoDB. Because I want to use noSQL, this looks cleaner to me.(Again not much experience) Edit There is a ORM mapper for scala mongodb in play2 https://github.com/leon/play-salat
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
What are the strengths of each framework?
Posting this after spending a week or two with Lift doesn't really
serve anybody's interests. However, I want to spend some time correcting
some mistakes and mis-perceptions.
For the security I don't think that is the job of the framework.
You're dead wrong. Security is the job of the framework. It's critical that security
is done by default rather than relying on each developer to understand every
security vulnerability and make sure every line of code takes that into account.
All we have to do is look at what happened to GitHub
to understand that even the best coders using well known technology
can make a critical mistake.
Lift gives a solid security layer on top, so by default, there's no XSS, CSRF, etc.
but the developer can dig down as deep as he wants to the HTTP request and deal
with the bytes on the wire.
Stateless/Stateful : It is hard to tell where the main differences are. I only know that play has also a state if you use web sockets.
Lift is very clear about where you need state and where you don't. Lift can support
stateless, partially stateful, and completely stateful apps. On a page-by-page and
request-by-request basis, a Lift app can be stateful or stateless (for example,
in Foursquare, the venue pages are stateless for
search engine crawls, but stateful for browsers that are logged in.) For
more on the design decisions around state, please see Lift, State, and Scaling.
Both frameworks are using sbt
Lift uses Maven, sbt, Buildr, and even Ant. Lift is agnostic about the build environment
and about the deploy environment (Java EE container, Netty, whatever). This is important
because it make Lift easier to integrate with the rest of your environment.
Lift comes with authorization but I think there is a play2 scala plugin that does the same thing
Lift has been around for 5+ years and has a lot of modules and stuff for it. The Lift web framework (as distinguished from the modules) is agnostic about persistence, authentication, etc., so you can use anything with Lift.
Async - Play 2 uses Akka. Don't know what lift uses but they also have something similar.
Lift has had Async support for more than 5 years. It's baked into the framework. Lift's Comet support is the best of any web framework because,
among other things, it multiplexes all the "push" requests on a page through a single request
to the server which avoids connection starvation. How Lift does async is a whole lot
less important because one of the core philosophies with Lift is that we remove the
plumbing from the developer so the developer can focus on business logic.
But for those who care, Lift has the best and lightest weight actors of any framework in
Scala-land. We were the first to break away from the Scala Actor's library and worked
to blaze the trail for different Actor libraries that allowed Akka and ScalaZ Actors
to flourish.
Lift ships with CSRF support. Play2 has a modul for CSRF but this adds a boilerplate to your code.
This is part of Lift's commitment to security. It's important.
Stateless authentication seems to have some security vulnerabilities. Both frameworks have the stateful authentication. (play2 stateful/stateless , lift stateful)
Lift apps can be as stateful or as stateless as you want. It's your choice and Lift
makes very clear how to make the decision.
Also, as I pointed out in the Lift, State, and Scaling post, making the developer figure out
how to serialize state in a secure, scalable, performant way
(because virtually every request on a web
app that recognizes specific users is stateful) should be done in a predictable,
secure way by the framework with reasonable overrides for the developers.
Parting note
Play is a lot like Rails: it's quick to get a site knocked together and it's
based on MVC, so a lot of developers understand it. But Play lacks the
depth and breadth of Rails (community, plugins, expertise, talent, etc.) If you
want quick, easy MVC, then go with Rails and JRuby and write your
back end in Scala (they work together extraordinarily well.)
Lift is a different beast. There's a significant unlearning curve (stop thinking
MVC and start thinking about user experience first that flows to business logic.)
But once you're up the unlearning curve, Lift sites are more secure, highly
scalable, super-interactive, and much easier to maintain over time.
To see what can be done with Play (it can be cool), have a look at the TypeSafe Console
To get going quick with Lift, use a template project.
For a sample of using Mongo with Play, look at Factile.
In summary, I don't think you will go wrong with either Lift or Play. Both are active projects, with good communities and good backing from the authors. It really depends on your business problem. If tool support are important to you, then you may want to look at using Play (it's well supported on IntelliJ Idea).
Take note that Play, being part of the TypeSafe technology stack, will have builds up to the latest versions of Scala, so if using Scala 2.10 features are important to you, then you may want to keep that in mind. Lift is currently using Scala 2.9.2, which is fine also.
For my current project I use lift-mapper for ORM (It's great and rock solid), with Spray for REST (which is simply amazing). This approach avoids frameworks altogether, but it depends on what you want to do. Frameworks are quite often the way to go.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Currently we are using GWT Platform with MVP architecture for our UI development.
I could see that we always get an advantage of using SmartGWT or GWT-Ext over GWT Platform because there are many built in components which are hard to write in regular GWT widgets.
I have following questions now to proceed.
1. Can we install GWT-Ext or Smart GWT over regular GWT P project and work? i.e Existing screen functionalities will remain with GWT regular widgets. But new development will be used with either Smart GWT or GWT-Ext. Will there be any conflict or issues in doing this?
2. With Smart GWT or GWT-Ext, can we still follow the same MVP framework like in GWT-Platform or we have a different mechanism for server side calls?
3. We wanted to use free licensing products. So SmartGWT and GWT-Ext are free softwares if I understand. Am I correct?
4. Now with both Smart GWT and GWT-Ext coming into picture, which one should I start using it considering, I will get more good components, faster development, good documentation help and good future for the technology. Now it is very difficult to make a choice of what to use? Please suggest.
In case if you feel, there is something else which is the best compared to these and free, you can suggest that as well.
Thanks in advance.
I will conclude as below with many links, comments on my question. SmartGWT is preferable over GWT-Ext when compared to available widget libraries. Also, GWT-Ext support is not much whereas
SmartGWT has enough support even now. SmartGWT is free to use. Also, we can start using SmartGWT on top of our existing GWT Platform application for our further development. With your above comments, I got to know that its not a good practice to mix GWT and SmartGWT widgets. But we can always start using all SmartGWT widgets for our new UI work. i.e You will have screen both from GWT widgets and SmartGWT widgets(Newer screens). Please confirm if my understanding is correct.
Now I have my last question which is very important - All current server calls are GWT Platform RPC calls - using GWT MVP framework. Service layer is built using GUIC framework. I would like to migrate to SmartGWT with minimal efforts. i.e
Existing GWT Platform screens are kept as it is with GWT - RPC calls to GUICE servlet framework
New development will be done using SmartGWT widgets, but would like to have Restful WS calls to GUICE framework. Even though SmartGWT provides data binding mechanism for better server calls, I may not be interested as we have an intention to convert all client server calls to Restful webservices with JSON. Do we have any issues in this approach where SmartGWT is used for better UI development, but with server calls being implemented using Restful Web services (JSON data format). Can somebody help me on how we can implement this behavior? I want GWT client and service to be independent(Technology independent) and hence would like to go for Restful Webservice approach for client-server communication. If we have any SmartGWT sample with restful webservice call it would be really great.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What do you think about both?
I began reading a book about Catalyst, and found it pretty complex as compared to Dancer.
so now I'm giving Dancer a try, and it looks easier to learn and more "human friendly".
I think David's comment is very accurate and excellent. However, as someone who has done development in both but is not a developer on either perhaps I can be slightly more objective (and technical) in what the differences are.
Both frameworks provide a variation on the Web MVC paradigm.
Catalyst's main level of abstraction is the Controller. Catalyst expects you to break separate logic out into separate packages in some logical fashion (Login code goes here, Registration code goes there, Search functionality over here). This works incredibly well if you have a team of programmers since each of you can work on separate files and not step all over each other during merges. Catalyst provides a lot of tools for making the Controller logic extensible and flexible, I think the premier example of this is Chained actions which let you split up and build a complex flow for any given request. The downside is that it becomes very seductive to put your business logic into the Controllers and you end up with very fat logic in the Controllers where it (theoretically) belongs in the Model.
Dancer's main level of abstraction is the Route. My experience with Dancer is this leads to much smaller applications. Partly my experience here is tinged with the fact that I have dealt with several thousand line applications in Catalyst but I have yet to write a Dancer app that is longer than 200 lines (with a much smaller scope). I think however that this experience holds true. The push in Dancer is in keeping the Controller logic very thin because it doesn't have the same tools for managing complex behaviors there that Catalyst does.
Honestly I've enjoyed working in both of them. They both provide different opinions on what writing a web application is supposed to be. I would, given the time and inclination, recommend learning both ultimately.
This is a somewhat subjective question, but I'll try to give you an answer in an objective way. First things first, a disclaimer: I'm part of the Dancer development team, so my opinion should of course be considered somewhat biased :)
Catalyst is more widely used than Dancer, and so there's more community support behind it - if you were to look for contractors with experience working with either framework, say, you'd be more likely to find developers who've used Catalyst. So, if you're looking for commercial support, that would be a good reason to choose Catalyst.
Dancer is a younger project, and targeted more towards smaller projects, making getting up and running quick and easy, and trying to stay out of your way. That's not to say that Dancer isn't suitable for larger projects, however; the same habit of staying out of your way means you can organise your project in the way that suits you.
However, it has picked up a lot of support, and there's a growing community of helpful users and developers on IRC and the mailing list, and more and more useful plugins being released all the time. As with Catalyst, Dancer is designed so that you can pick and choose your preferred template engine, session storage backend etc, and it's easy to extend the framework by writing your own plugins if you need to.
For user testimonials to see what people say about Dancer, see the section at the bottom of the homepage on the new website: http://www.perldancer.org/
In the interests of showing other options, there's also Mojolicious, another modern Perl web framework which has been gaining in popularity lately.
Catalyst provides the same abstraction that Dancer does, Dancer's strength or rather Catalyst's weakness or rather Dancer's weakness is in how Catalyst forces the developer to adhere to Perl OO best practices and the MVC design pattern. After doing webapps for a while, this will all become apparent.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My team and I are beginning to plan the development of a modular application which will likely multi-target WPF & Silverlight.
I personally have some experience using the older version of PRISM to build a composite Silverlight app using the MVVM pattern. We weren't familiar with MEF at the time for handling the various module dependencies, so we didn't use it.
We aren't married to any particular framework, but want to use one of the bigger players out there. As such we've begun to examine Caliburn/Caliburn Micro, Prism, MVVM Light and Reactive UI.
Most of what I've read for modularity suggests PRISM and MEF to handle that part of the process. As I'm still wrapping my head around some of this, I'm not sure if I'm missing some obvious options. I was able to find this article on Caliburn Micro and MEF.
Can anyone point me to similar articles using some of the other frameworks to compose a composite app similarly to the way PRSIM uses Regions, etc? Ideally, I'd like to limit the number of frameworks needed while providing maximum flexibility. We aren't averse to taking a "best of breed" approach and using for example MEF/PRISM to handle the compositing and MVVM Light for the View management, etc; but why use 2 when 1 will do?
One thing you should probably do first is isolate these into their appropriate buckets. I see this a lot where people will mix MVVM frameworks with application composition frameworks. Once you have them in the appropriate buckets you can start to pick one framework from each category and combine them into what you consider to be the best scenario.
Application Composition
Prism (using any IoC container: MEF, Unity, Ninject, Autofac, etc. There are a few things that make MVVM easier with Prism, but I wouldn't call it a fully featured MVVM framework... it's primarily a modular application composition framwork.)
MEF (MEF is actually able to do application composition out of the box. It's often dismissed as just an IoC framework, but it is deceptively powerful.)
MVVM Frameworks
ReactiveUI (my favorite)
Caliburn
Caliburn Micro
MVVM Light
This will help you make a decision, I think. You can pick and application composition technology you like and an MVVM framework you like and be off and running to the races.
As for articles, I don't have too many. There are a lot of good articles on application composition with Prism (that's pretty much its job), but here is a good article on application composition with MEF by itself:
http://blogs.microsoft.co.il/blogs/tomershamam/archive/2009/08/11/wpf-mef-declarative-composite-ui.aspx
You should also check out Glenn Block's series "Building HelloMEF" on his blog. I couldn't find a comprehensive list (he wasn't consistent with his tagging), but here is the "MEF" tag. Lots of good stuff here:
http://blogs.msdn.com/b/gblock/archive/tags/mef/default.aspx?PageIndex=1
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I would like to learn more about how to use Selenium IDE and RC for creating good automation tests. Is there anybody who is interested in sharing info. or discussing this? Especially for things like:
1) What's a good way to organize the UI tests? Right now I am executing these tests thru NUnit and that executes the tests in the order of their alphabetical names. Is there a better way. (I am writing the selenium scripts in C# and not java)
2) How are the results logged?
3) Modularizing the Selenium RC tests? I am having a problem here. Since I am executing my tests thru NUnit, the only way I could figure was to give IDs to the tests so that they get run in the right order. Also I am having to write all my tests one after the other in the textfixture class. Again is there a better way? I tried creating additional files but when I create tests there and select them to run in NUnit, it looks like the selenium server doesn't even get started.
4) What are the best practices for automation testing? Any pointers to any sites/books/ etc.?
These might seem very simple things but I've spent weeks trying to come up with better ways, so if somebody is willing to offer suggestions or input I'll really appreciate it!
Thanks!
I have answered each of the questions for you below.
Tests shouldn't matter about the order that they run in. If you start worrying about that you are going to start introducing flakiness of tests. If you have to login with each test do so, if you need to register a number of users during your tests do so. Tests should always be able to run on their own.
Nunit logs its results in a XML file. This will have a list of the passes and fails and is normally rendered in a pretty fashion by nearly all Continuous
See my answer for Best Practices for modularizing Selenium RC test scripts
Tests should always have a known starting point. In the context of Selenium this could mean opening a certain page to start a workflow.
Tests should not have to rely on any other tests to run. If a test is going to add something do not have a separate test to delete it. This is to ensure that if something goes wrong in one test it will not mean you have a lot of unnecessary failures to check.
Tests should only test one thing at a time.
Tests should clean up after themselves.
If your desires is to use Selenium then I can suggest instead use the TestPlan front-end instead of another language. In additional to a domain specific language it offers nice test case management. You can organize your tests into a nice hierarchy and it will execute all of them and report the results.
It takes care of a lot of details of launching Selenium and smooths over many difficulties in the RC API.
I've just went through this. In terms of modularizing and useful tools. I think it's really important to think more about building an agile, well maintained automated ui testing framework than simply modularizing selenium RC scripts. Selenium 2: Testing Tools Begginner's Guide was a great start for idea how to start building a good testing framework. I had MUCH success with the (Page Object pattern)[https://code.google.com/p/selenium/wiki/PageObjects] after failing 2-3 times getting an automated testing framework going. In terms of proccess, I found it best to start by writing code (you are writing tests, so it should be pretty easy to test), but aggressively refactoring using good OOP as patterns and structures begin to build up. I'd also reccommend How Google Tests Software for motivation of Software QA in general, good testing practices on an organizational level, and when and when not to use automation.