I have been tasked to setup a continuous integration environment for a GXT 2.1.1 and GWT 2.0.1 environment. Unfortunately I am new to AJAX and Web Services and have little idea how to setup unit tests in the browser environment. Unit tests for the server backend I already have done, since I am a pro at that. GXT is not quite pure GWT which provides some unit testing structure. If anyone has a good starting point...
I feel the article here is fairly elaborate, Have you gone through that ?
I am assuming you are planning to test only the Async's and Server side (RemoteServiceServlet) part, so I don't understand how gwt/gxt differ in that, all the rules that apply to GWT, will still apply to GXT testing as well.
I think the best approach is unit testing and I will recommend using JUnit .
Related
I am wondering about how can we testing automate functionality.
I am working on a Spring Boot micro-service where we use a GemFire cache. Right now I am testing it manually for below scenarios:
Is the data purged correctly after TTL is reached
Retrieving the data from cache if object exists
So, I know we can have a separate service which calls the GemFire and making sure that the object exists in cache (for step2). But not really sure how can we automate testing for step1.
And the whole point I am wondering is do we really need a new service completely to test this as a overhead? Are there any tools / better approach for testing the functionality?
Since you're using spring-boot and VMware GemFire together, I really hope you're taking advantage of the huge help and functionality spring-boot-data-gemfire provides out of the box. If you are, then you'd be delighted to know that there's yet another project, spring-test-data-geode, which can be used to write Unit and Integration Tests when building Spring Data for Apache Geode & VMware GemFire applications, you should really give it a try as it greatly helps in managing the scope and lifecycle of mock VMware GemFire/Apache Geode objects, along with cleaning all resources used by real objects used during Integration Tests.
As a side note, if you're using the Data Expiration Functionality shipped out of the box with VMware GemFire, I really don't see an actual need (other than the peace of mind that comes with I've tested everything I could) to include custom tests within your testing suite, you should only test what you own. The functionality itself is thoroughly tested already as part of the VMware GemFire / Apache Geode project itself, and you can see some (certainly not all) examples of such tests in the following links: ExpirationDUnitTest, RegionExpirationDistributedTest, ReplicateEntryIdleExpirationDistributedTest.
Cheers.
I have had some success using TestContainers here is the code used to create the container and
a sample test. It works by executing gfsh commands on the container but is slow.
I would like to set up an infrastructure for integration testing.
Currently we bootstrap tomcat using maven and then execute httpunit tests.
But the current solution has few drawbacks.
Any changes committed to the database need to be rollback manually in the end if the test
Running code coverage on integration test is not straight forward (we are using sonar).
My goals are:
Allow automatic rollback between tests (hopefully using String #transaction and #rollback)
Simple straight forward code coverage
Using #RunWith that will bootstrap the system from JUnit and not externally
Interacting with live servlets and javascript (I consider switching from httpuinit to selenium…)
Reasonable execution time (at least not longer than the existing execution time)
The goals above look reasonable to me and common to many Java/J2ee projects.
I was thinking to achieve those goals by using Arquillian and Arquillian Spring Framework Extension component.
See also https://github.com/arquillian/arquillian-showcase/
Does anyone have and experience with Arquillian and with Arquillian Spring Framework Extension?
Can you share issues best practices and lesson learned?
Can anyone suggest an alternative approach to the above?
I can't fully answer your question. only some tips
Regarding the automatic rollback. In my case. Using liquibase to init the test data on "hsqldb" or "h2" which could be set as in-memory pattern. Then no need to roll back.
For Arquillian. It's a good real testing approach. What i learned is that "Arauillian Spring Framework Extension" is just a extension. You have to bind to a specific container like "jboss, glasshfish,tomcat" to make the test run.
But i don't know how to apply for a spring-based javaSE program which do not need application server support.
My lesson learned is the jboss port conflict. since jboss-dist is set 8080 as default http port. But our company proxy is same as 8080. So i can't use maven to get the jboss-dist artifact.
Hope others can give more info.
We are having a setup of 3 different Java EE Servers, all communicating with both JGroups and RMI. We are heavily unit testing our code and the whole team is totally in favor of TBD, but we are facing problems when it comes to integration testing our servers.
Especially our custom fail-over/ reconnect/ termination detection "algorithms" would need some automated testing because we are often seeing that they break and we currently always fix it by trial and error testing.
We are using the following libraries/frameworks: Tomcat, Maven, Spring 3, RMI, JGroups
Any ideas, suggestions, links and resources are welcome!
Interesting that nobody answered this question since 2011. Maybe there wasn't anything to recommend?
If you are looking into integration testing only it's much easier. You can write your usual JUnit/TestNG tests and use arquillian to take care of the container (lifecycle, deployments, configuration, etc). You can run all the components (tests, containers, deployments) on a single node, bind to different IPs or ports, let JGroups do all the cluster communication as usual.
http://arquillian.org/
Moreover, there is a whole book now available about integration testing in called 'Continuous Enterprise Development in Java'.
http://www.amazon.com/Continuous-Enterprise-Development-Andrew-Rubinger/dp/1449328296
The situation is IMO much worse when it comes to system testing. I am going to just say one name here: SmartFrog which is 'powerful and flexible Java-based software framework for configuring, deploying and managing distributed software systems'. The learning curve is terrible though.
http://www.smartfrog.org/
I have developed a stack of web Services based on:
Spring ws 2.0 with jaxb2 maven plugin (to ease the pain).
Hibernate.
PostgResql.
We are using the following to test:
Junit test with Mockito.
Spring test for Dao & service layer.
The new Spring ws test & Smock api.
SoapUi Api for testing with their maven plugin.
We have TracWiki for the wiki side.
All is fully automated in a maven build with Hudson, even the deployment of the webapp with cargo
on distant server.
We have 5 virtual servers on a single machine on Debian (using vserver).
We don't have a single performance test and we don't have any webapp tools to monitor.
What do you recommend to go a step further?
I'm really looking for new ways and/or tools to improve everything.
Hey.
Incorporate Sonar into your builds. You will get lots of informations about your code.
I don't see you mentioning any code coverage tools. While coverage isn't everything, it can help finding the parts of your code which aren't covered by the tests (or perhaps even dead).
We have a large infrastructure that's highly dependent on Spring Framework. Recently I began writing code in Scala and test it using Specs. This is all great but at some point I need to use Spring-dependent features (Such as a HibernateDaoSupport-based DAO).
Has anyone managed to use the SpringJUnit4ClassRunner class to run Specs tests? Does anyone have a different direction as to how to achieve this goal?
Thanks
I've struggled with the class runner in a similarly awkward scenario once and then I created a MethodRule implementation called TemporarySpringContext that could also solve your problem I think.