What sort of a framework can be used to test a jsp web application?
All java classes and the servrlets needs to be tested too. What would be the best approach and related frameworks that can be used in this regard?
Update
Any other suggestions?
For the Java part I still recommend JUnit as Unit-Test-Framework.
For the test of the web part one can think about using a web test framework like Selenium. However, this part is more difficult to automate during (for example) a nightly build.
You can test your application front end with selinium webdriver automation testing.
you can test your java code with junit framework or
testNg now a days becoming more popular in the market
JUnit was selected as the testing framework for java components. Still looking for a method to test application front end?
There is a tool called JspTester (http://jsptester.com) which integrates as a servlet to your webapp, and allows to inject values directly to beans, model objects, request parameters and session variables. Useful when there is a need to test the JSPs in isolation from business logic or MVC controllers.
Related
I have two Spring applications which interact which each other via database and some AMQP:
web-application built on Spring MVC
Spring-Boot application
Each application has its independent context and properties files.
What is the proper way of writing single integration test for these two applications?
More specifically: I can merge this two applications in one maven project in order to have access to both of them.
Is it possible to configure test contexts for both applications in
one Spring test? At the moment I have no idea how to tell spring use different contexts for different applications in one test.
Another purpose of this testing is also to obtain code coverage for these two applications. That is why I can not just start, say, Spring-boot application as separate process. Is it possible at all?
Spring's test module brings up a single application context (take a look at the key abstractions section of the official documentation) per test so no, you cannot have multiple application contexts per test.
What you can have is a merged application context that imports both the Spring Boot and Spring MVC application's context; that way, you can test beans from both applications. However, this is probably not what you want to do and it's something I would recommend against - your tests will become almost worthless since making this approach work could probably entail some hacks and you will not be testing your applications realistically given that they will be deployed separately.
You should write per-application integration tests and measure coverage for each of them. If your application is relatively small, you can have an end-to-end testing module that would leverage Docker containers to create an environment similar to your production and verify that your applications correctly work together.
We are currently developing a trade project with Richfaces 3.0, Seam 2.2 and JBOSS 6.0. And we are using Selenium for our GUI tests. I just want to know if there is any possibilty to access beans in selenium tests.
No, Selenium and Seam beans are a completely different level of abstraction. Seam beans are running inside a JBoss server while Selenium works on top of a web browser.
If you want to somehow control the application from the inside, you must provide some interface for these beans that is accessible via Selenium test. For instance you might expose some operations as web services or JMX beans and access them from Selenium test suite if written in Java.
Note however that this is not the best practice - Selenium tests should only work on user interface (end-to-end) level. Try to setup your application only via the user interface rather than manually accessing application internals.
UPDATE: If you have some common setup (like users, products, etc.), insert them in your database as part of your common deployment infrastructure. Then you can have a single test for creating/accepting a user, adding product, etc. and then simply reuse the common users already existing in the database.
There's nothing technically stopping you from allowing selenium visibility to your beans and call methods on them directly. However, it won't be a good design practice. Selenium is for testing the behaviour of your applications (through GUI, mostly) and should not be concerned with bean level. Maybe if you give us a use case of why you may need to do so it may make sense?
In the past I have exposed web services and JDBC tests via selenium as a shortcut for QA people to test certain parts of the application, if that's what you are talking about, but it may be best to use it via web services as Tomasz mentioned.
I am working on Big Spring, ibatis, velocity bases J2EE project there are thousands of classes and number of service layer classes, i need to create test cases for all server layer classes is there any automated tool to write test cases for all service layer classes ?
No.
You need to figure out what you application does, split it up into components that are testable, and then write tests for those components.
Sorry.
Unfortunately no automated test case generator tool exists.
what are the best practices to unit test java servlets? By the way: this is a topic in which I have some dificulty: how do you unit test your java servlets?
The most important thing to do is to try and extract everything from the servlets that isn't directly related to servlet behaviour.
This immediately makes testing core functionality a lot easier. By doing this you immediately have a set of components not tied to the container and testable without the pain of running and interfacing to a container (besides making them more reusable). Some thought should be given to architecture and the appropriate layering of components - e.g. components returning object structures rather than displayable fragments, not making use of HttpRequests directly but some request marshalling structure etc.
The majority of your tests (dependent on your system structure and complexity) can be tested normally. Additional servlet-focused tests can be built using (say) Apache Cactus to sanity check functionality. Beyond that you may wish to investigate in-browser solutions such as Selenium.
(Note: This approach works for most GUI environments - e.g. Swing)
Almost the same question was asked just today here.
Jakarta cactus is a unit-testing framework for servlets.
What we normally do is load the servlet with a mock request and response. If you're using Spring, this is especially easy since it actually provides a MockHttpRequest and MockHttpResponse.
Assuming you have clearly defined layers in your application, the rest is easy. The underlying service / DAO layer can be replaced with mocks, so we just make sure the servlet is doing what its supposed to be doing for the given request object, and writing the response correctly.
im using Struts 1.2.x and Ibatis 2.x version for development, so i finish yesterday and now i want to perform test this is my first time trying to work with JUnit, I already make test but in JavaApp not running on server, so how can I simulate or generate mocks with server behavior, and wich mocks are recommended for Struts and Ibatis built-in Environment?
for example how can i set accerts for login screen?
I know about StrutsTestCase im using it, and about Cactus are for containers and mocking for non containers scenaries, i want to view a demo using struts and ibatis cause I dont know how to retrieve data from mapping. Thanks
sorry about my English
Thanks in advance!
Have you looked at HttpUnit? I tried it for Servlet testing, completely different from Struts Actions and such - I know, but it had some decent tutorials.
You also might want to look at StrutsTestCase for JUnit. That project should be a sufficient start for unit testing struts. It also mentions Cactus, which is a framework for testing web applications on the server side.
Actually it all depends on how far you want to go with testing. You probably should have started with writing a test first, Test Driven Design you know ;) It just works. Not that I do it all the time...