Normally, when I implement new features, I write corresponding automation test code. But right now we are working on a special project. I don't know if it is good practice to write automation test code.
The project is a legacy project, which doesn't have automation test code. The functions are stable they been there for years. We do not add any new functions to it, and we probably won't in future. We need to change the UI from flex to html, so we need to change the way how we expose APIs. We used to expose API through spring remote. Now we switch to RESTFUL APIs. In other words, we only write wrapper code. We don't write if...else.. or loops. Is it a good practice to write automation test code for the mid-tier in such case?
Yes.
A unit test could verify the parameters passed to the API were correctly passed on to the wrapped component. In this case the wrapped component might be mocked.
An integration test could verify the API (facade) correctly wired the real components, and assert the expected result.
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.)
I want to run my JUnits on demand via RESTful api. These are primarily the functional JUnits which test the RESTful endpoints, so they don't directly test source code.
Is there any tooling available to scan existing JUnits and provide those a list of available tests along with the ability to execute those tests.
I am thinking of something which similar to the following REST calls --
GET unit-test-service/tests (to get the list of tests)
GET unit-test-service/tests/123456?execute=true (to execute the test and return test result as response.)
Any pointers are greatly appreciated
Try using Fitnesse it is a simple wiki based testing tool having test classes in Java or other languages. It also has the REST urls where you can retrieve test cases as xml and parse it or run it as well.
I would like to know what would be the impact if a unit testing framework (for Java specifically) does not use any of the Reflection facilities. For example, if junit doesn't use Reflection at all to invoke tests, what will be the impact on its usage or features that it currently supports. Are there any alternatives to match the flexibility of Reflection APIs?
Reflection is used for configuration purpose. So the runner will know what methods to run for test and what methods to use for the setup and teardown of the tests. You could put that kind of configuration in an external file like xml and read it from there.
After knowing the names of the methods for running, reflection is used to actually allocate the methods and run them. I don't see a way you can do it in another way unless you actually write a some kind of a function in which you specifically call each test method. And then call this function in a main test suite function. Or you could make a preprocessor that write that kind of function for you from the information you specify in the configuration. But why would you want to ? It will only save you the time of the test runtime checks vs the one time compilation. It has very little advantage.
I am developing a REST API. I have Jmeter tests already for the functional testing. I wanted to add unit tests and also want to follow test driven development(TDD) from now on to make any enhancement and add new functionality to my existing project (which is bound to grow very complex and does not have any unit tests in place).
After reading a lot about TDD I am little confused about whether I should be going for TDD. There are extreme outlooks for and against it.
I think I will follow TDD only to develop my service layer, which encompasses only business logic.
Any suggestions about my approach ?
TDD is more than that. It is not only a way for you to check if a system is externally working fine. TDD is also a means to accelerate development of your classes, even if they do not interact with other systems.
Think of a test as a response to the following questions:
Am I done developing this class?
Do the classes I already developed and tested still work fine after a change I've made?
How to represent requirements as source code?
An explanation about each question:
How do you know you are done writing a class? A test can tell you that by only showing a test successful message after your class does everything it was supposed to do.
You need test automation in order to test often.
Whenever you have a new requirement, write a new test that represents this requirement.
TDD is one of the best practices to follow as you would test before you develop. And you would know at each and every step during developing the application/service if you have broken any previous functionality.
You are at the right path and I would always encourage using TDD. If you are working on a project right from scratch then just go for it.
Since yours is an existing project it may be a headache at first till you cover unit test cases for all the existing functionality.
So the best approach is:
Write down all the unit test cases for existing functionality before you start development for new functionality.
While doing that you may come up with a lot of surprises and may end up re-factoring a lot of code. This will help you while developing future new functionality.
Now since your code looks much better you can start TDD for the new functionality.
Let me know if this helps. I have used TDD in many of my projects and I am comfortable with that.
Since you're using Spring, I'd suggest that the object to unit test should not be a web service. I'd make it an interface-based POJO. The behavior should not be affected by the choice to deploy as REST.
Marshaling and unmarshaling the HTTP request and response to objects for the POJO to consume can be separate.
This arrangement will have the added benefit of not requiring deployment to a container in order to test.
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.