I want to create a test suit for my java web application. Its a JSP applications with JDBC connectivity . My requirements are as follows,
1 - I should be able to test my database logic (Queries etc) through my models.
2 - Its great if i could test my .jsp pages as well (if possible)
After doing some research I found that DBUnit is good for database backend system testing, but unfortunately i couldnt find any good resource as a starter
What are you all think about testing options I have and it would be great if you could post some links to resources/ examples as well
EDIT:
and I have come across with mock objects (like JMock..), wonder I could use it as a replacement for DBUnit ?
thanks in advance
cheers
sameera
It's not clear from your question if you want to run Integration tests (Front end + back end) or Unit Tests against you Database layer.
If you need a tool that allows you to write Integration tests, you should definitively look at Selenium.
With Selenium you can generate functional tests by simply navigating your web site (JSP pages) and asserting that stuff on the page exists or it's equal to some values.
Selenium comes with a Firefox plugin that will basically generate the code for you. You can replay the test in the browser or export them as Java code and make them part of your test suite. Selenium is an invaluable tool.
The drawback of using a tool like Selenium is that your application need to be deployed somewhere before you can run your test suite. This may be a limitation if you plan to run automated tests generated using Selenium.
If you are only interested in testing your database access code (DAO, Data Access Layer) DBUnit is the perfect tool.
Generally, DBUnit is used to initialize the database tables before testing and, less often, to run assertions on the database content. DBUnit uses an XML based format to represent the data that will be inserted into the database.
The XML files containing the data to pre-populate the db are normally triggered by a build script (Ant, Maven, etc.) or directly in your unit test code.
I have used both approaches, it really depends on how your code is structured and how you access the database (Hibernate, Spring+Hibernate, JDBC...).
If your database is not too big, I'd recommend you populate it just before running your test suite. Alternatively, you can populate only the tables that you are interested in testing prior to every test.
Here is a link to Unitils, that is an additional library that can be used on top of DBUnit to simplify the database testing strategy. I think it can be used as a reference to get you started:
http://www.unitils.org/tutorial.html#Database_testing
Here is anoter link (quite old, 2004) showing the basic mechanics of DBUnit:
http://onjava.com/pub/a/onjava/2004/01/21/dbunit.html
DBUnit's official getting-started article here worked for me. Re: database logic testing, you might also want to check this out.
As for JSP testing, I have used Cactus to test my servlets before with success. However, I'm don't know about its JSP-testing facilities.
For your 1st question have a look at this StackOverFlow thread...
For 2nd, I would go with Chry's suggestion of Cactus or Selenium.
Hope that helps.
Related
I am a Java developer. We want to use cucumber testing in our project. We are working mainly on creating APIs. I am good with unit testing and researching about cucumber.
I am thinking about testing persistence methods - CRUD operations as an starter. My questions is that what could be the scenerios in this testing.
Also should I mock the database by creating tables in the feature file. Should I use mockito with Cucumber to mock call to some other services which connects to database and server.
What should be the cucumber testing in these scenerios and whats the best way to create framework to use cucumber in our Java API's project.
Also, how to populate models if not using database
IMO Gherkin (the language you write Cucumber features in), is good for writing business readable, simple scenarios.
To answer quickly, I would say that Cucumber is not a good fit for testing methods, if it is what you want to do.
As you can see with the file naming convention, you write *.feature files, and I think these files must only contains feature-related descriptions.
However, if you do have features to test, you have to choose how to test them
disconnected, can be run quicky by your CI
you will have to mock everything that cannot start-up in the build lifecycle
and they are solutions to start almost anything using Docker, like Testcontainers
connected to a environment
you do not have to mock anything
your tests may be slower
your tests may break because of the environement (failed deployement, server down, etc.)
If it required to write a script for minimal usage of SQL for database testing of a website using selenium or manual testing is enough?
Not selenium (a browser tester), but you could use JBehave.
You should be using JBehave (or similar BDD tool) to drive your system testing.
You could do it via unit tests, but I wouldn't because it requires a database to be present and that's typically outside the scope of a "unit test". No point in using a mocking framework either, because it;s the database you want to test, not the code calling it.
We use TSQLT. It a unit test framework but I use it as an e2e test automation tool. You can fake tables in Stg, ETL and target. Then you can write scripts that perform inserts, updates, deletes etc., run stored procedures and then compare expected vs actually results. Work pretty well and easy to use
I have a doubt. Say I have a web application which is big and relies on Java/Java EE (JSP/Servlets).
Every time before a drop we test each and every functionality on GUI so that everything is working properly. Previously it was easy but now as the number of modules has increased exponentially, manually testing each and every GUI with required functionality is no more a feasible option.
I am on lookout for tools in which I can write my entire test case say about 1000 and then just run it once before the drop and it will list down all the test cases that have failed.
The tool preferably must be free to download and use it.
I dont know whether using
Arquilian
or
JUnit
in this regard will help or not but automating testing before the drop is really needed..
Please guide.
Use Junit together with a mock framework i.e Mockito to test units (service methods)
Use Arquillian to test on an integration level ( how different services, modules work together )
Use a database testing tool (i.e dbunit) to test your database / persistence layer)
Use Selenium to test your frontend
Test as much as possible.
Use Jenkins and Sonar to track your build process and your quality of tests and code
You should always test your application on different level. There is not just one solution.
Use unit testing to test small pieces of your application and to make refactoring as easy as possible.
Use integration test to check your modules still work together as expected.
Use GUI testing to check if your customers can work with your software.
If its relevant, think about performance testing (i.e. jmeter )
Definitively Selenium. Couple it with maven cause you will probably need to package your project specifically for testing purpose. Moreover maven allow you to launch a container during the integration-test phase and to close it automatically at the end. You can also configure this as a nightly build on jenkins / hudson so you will be quicly notified of any regression.
This may sound like a vague question but I am looking for some specif pointers.
Our J2EE app is built on Struts2 + Plain Servlets + JSP + iBatis + Oracle
I would prefer to write unit tests in Scala so that I can learn the language on the side as well
What would I need to be able to verify that a spcific column is displayed in the JSP following some specific steps
Click on a link. select some parameters and submit the page to the servlet
Verify that the next page has a specific column inside its <table> tag.
What would I need to create mock requests for the serlvet?
I am trying to write tests like above in addition to core business functionality tests however, the problem is that I am trying to wrap legacy code in unit tests and the code of course is not designed for unit testing.
I wouldn't call this unit testing. As you are trying to test integration of several units. Also it's rather hard to create a unit test for a JSP becuase it has many context dependencies available only when you are in the container.
Instead I would advice writing some automated functional tests that are executed against running (deployed) application.
Frameworks like Selenium may be of great help here as they allow to simulate real user behaviour and make asserts against produced HTML code.
EDIT: Another approach here may be to:
start an embedded servlet container like Jetty within your test code
deploy all your plain servlets and JSPs to that
replace Oracle database with in-memory database like HSQL or Derby
populate it with some test data using DBUnit
and then again use either Selenium (which has Java binding) or HttpUnit to make requests and asserts against generated HTML code.
But again it will not be a unit test, but rather an integration test.
Like everyone said, your not really talking about unit testing. You're talking about functional testing. I'd think hard about what your real goals are. What is driving this push for automated testing? Does the application have configuration issues(i.e. its hard to configure so some parts work and others don't). This might justify building a smoke test suite in selenium targeting your pain pages and test cases. This will also help detect regression bugs.
As for the legacy concerns. No application is beyond help. If you are running front end tests in selenium then it doesn't matter how the code is written as long as its parseable HTML.
As for your actual server side code. You just gotta roll Andy Dufresne style. As you fix bugs and add functionality code with Test Driven Development principles in mind. Rework code that relates to your changes and add unit tests. You'd be surprised at how fast a legacy app can come around if you keep chipping away at it.
At work we are trying to simplify an application that was coded with an overkill use of Spring Remoting. This is how it works today:
(Controllers) Spring MVC -> Spring Remoting -> Hibernate
Everything is deployed in a single machine, Spring Remoting is not needed (never will be needed) and adds complexity to code maintenance. We want it out.
How to ensure everything works after our changes? Today we have 0% code coverage! We thought on creating integration tests to our controllers so when we remove Spring Remoting they should behave exactly the same. We thought on using a mix of Spring Test framework in conjunction with DBUnit to bring up Oracle up to a known state every test cycle.
Has anyone tried a similar solution? What are the drawbacks? Would you suggest any better alternative?
It always depends on the ratio effort / benefit that you are willing to take. You can get an almost 100% code coverage if you are really diligent and thorough. But that might be overkill too, especially when it comes to maintaining those tests. But your idea is good. I've done this a couple of times before with medium applications. This is what you should do:
Be sure that you have a well known test data set in the database at the beginning of every test in the test suite (you mentioned that yourself)
Since you're using Hibernate, you might also try using HSQLDB as a substitute for Oracle. That way, your tests will run a lot faster.
Create lots of independent little test cases covering most of your most valued functionality. You can always allow yourself to have some minor bugs in some remote and unimportant corners of the application.
Make sure those test cases all run before the refactoring.
Make sure you have a reference system that will not be touched by the refactoring, in order to be able to add new test cases, in case you think of something only later
Start refactoring, and while refactoring run all relevant tests that could be broken by the current refactoring step. Run the complete test suite once a night using tools such as jenkins.
That should work. If your application is a web application, then I can only recommend selenium. It has a nice jenkins integration and you can create hundreds of test cases by just clicking through your application in the browser (those clicks are recorded and a Java/Groovy/other language test script is generated).
In our Spring MVC / Hibernate (using v3.4) web app we use an Oracle database for integration testing.
To ensure that our database is in a known state each time the test suites are run, we set the following property in our test suite's persistence.xml:
<property name="hibernate.hbm2ddl.auto" value="create"/>
This ensures that the db schema is created each time our tests are run based on the Hibernate annotations in our classes. To populate our database with a know data set, we added a file named import.sql to our classpath with the appropriate SQL inserts. If you have the above property set, Hibernate will run the statements in import.sql on your database after creating the schema.