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.
Related
I'd like to know if any of You have experience in automation UI testing of modular-like apps. The whole app is like all typical CRM-related apps, where based on Your personal client needs You just put together some of the available modules (that have been predefined earlier) in order to provide all necessary functionalities.
If there would be "static" app built of all these modules put together then we could test it in a quite easy way, just going through all defined test classes, because we would know the behaviour/interactions between all these modules.
But in case we would need to test app behaviour while putting some of its random pieces/modules together in order to check if they work well, we would need some other approach.
If there's a solution, some recommended architect pattern or anything that can help me to perform such automation tests (using i.e. Selenium WebDriver)? Or does this kind of tests are even possible to perform using WebDriver library?
I'd be grateful if You'll share any of Your thoughts and experiences in this area.
I am working in that area and had a similar situation, here's what I learned from it:
Avoid creating UI tests if you can. UI tests are intended to test the look of your application and that's it. Business logic (like when I change that setting, the displayed data should change, etc.) should be tested in unit tests which are much easier to implement. Interaction between the modules should be covered as much as possible in integration tests.
If you still have functionality left over that needs to be tested, create a config file that contains the information about what customer has which modules enabled. In your test, read that config and if a test is not supposed to run, abort it.
In case some further researcher will look for the know-how solution for this case, we can just set some different test suites for each of app modules, and then we can check each suits for some certain condition met. If some suit won't meet this condition then we'll just skip this test suites. I.e we can get the app bundles.json file, which will most likely contain all information concerning app modules, and then we can just process this file to search for modules which are unavailable in current deployed app.
Look this as nice reference on how to achieve this: Introducing to conditional test running in TestNG
Today i begin a project that i must to spread a backend in two pieces, i dont know what exactly does the backend do, only that i have to move specific services into new spring, jersey, maven multi module project.
So, the task to move was really easy and now its time to write tests. Previously, the project does not have any test.
When i start to write a JUnits from my Business Objects, i saw, that most services only perform a basic operation with a DAO, like getAll, get, save, update and delete. The other services got bussines validation, but it is not comlpex.
So the questions are more theorical:
Should i write JUnits to test a simple DAO get that will be mocked (no integration test) which will be the benefits for do this?
Which will be the correct way to make a integration test for a simple DAO get, getAll, or create (create that does not have any validation to execute before)
Unit&Integration tests are for developers, so if you don't feel like some developer will benefit from the test - don't write it. Also consider that tests verify behavior, not code, so if you don't see any behavior that needs testing - don't spend the time.
In your case I would at most write integration tests for services, and maybe for DAOs (if there is no ORM).
Anyway correct answer to your question depends on the level of quality that you need to provide for your project, team size, potential of destructive code changes, etc.
Two examples:
1) Small site's admin-panel in CRUD style, only one developer introduces changes simultaneously, and almost no business logic is present. Bugs presence is non-critical.
In this case I would not spend the time on any tests - most likely you need to focus on other things (e.g. client-side).
2) You are starting a complex project, that is currently in CRUD style, but interactions between distant services/DAOs are present, business logic tends to become complex at some time. Team is rapidly growing/changing, more than one person involved, new developers can't understand how the system works easily. Bugs presence are bad for business.
In this case I would at least start with integration tests for services.
I'm currently working on one project, that uses Struts2 framework. We use separate component for DB accessing, which is well tested. At the same time, project, that we work on has a lot of Actions, that are not tested. In most of the actions we use at least one DB-service call. So on one hand these actions are pretty simple. I'm not sure - should unit tests be written for that or not?
I think that good practice is write unit tests always, but these actions are so simple and I'm under big pressure from management side right now. So, is it critical or not - to leave Struts2 actions without unit tests?
Here are the three main reasons for writing unit tests.
It helps you know that your code works now.
It helps defend your code against regression errors, when functionality is added or changed in the future.
If you write unit tests before you write your code, it focuses your design process in a really good way - read up on TDD to learn more about the benefits of doing this.
So ask yourself whether any of these three reasons for writing unit tests apply here. If the answer is "no" for all three questions, then consider the cost of writing the unit tests, and of keeping them in your code base. Compare this cost with the possible benefit. Make an intelligent decision about whether you should be writing unit tests, and be prepared to defend that decision to your manager.
But don't carry a preconceived notion that "unit tests are always good, for every class". And don't carry the opposite notion - that "unit tests are always unnecessary". Neither is true.
I'm in the same camp as Dhanji Prasanna who worked on Guice and Google Wave. Its not about 100% coverage, its about writing valuable tests that provide the right feedback for the right components in a way that aids development and protects against code regression.
For one of my Struts2 apps, we had very very complex data validation requirements. Thousands. We used the struts2-junit-plugin to test the action classes within their integrated context with Spring 3 IoC and Struts2 validation and a custom mechanism for populating mock requests with lots of different data scenarios. These tests were/are invaluable both during development and as a maintenance tool.
But for some of our simpler actions, I don't see much value coming back compared to the time spent to write them. But then, they don't take too long to write if they are very simple, either.
I have also seen cases where the 100% coverage notion led to 100% of classes having thoughtless, worthless tests being written for them. For my money, I vote for identifying the areas where the tests will provide the most value up front and focusing on doing those very well.
Must write Unit Test for functions could be problematic, but in anyway maybe in a future will be validations in the Actions that would be good can test that.
The time spend for test the actions must be a little bit and I would recommend do it, every tier in your app must have some functionally if not is a unnecessary and must review the architecture.
I am working on a web application with an existing code base that has probably been around for 10 years, there are ~1000 class files and ~100,000 lines of code. The good news is that the code is organized well, business logic is separate from the controller domain, and there is a high level of reusability. The bad news is there is only the very beginnings of a test suite (JUnit); there's maybe 12 dozen tests at most.
The code is organized fairly typically for an enterprise Java project. There is a stuts-esque controller package, the model consists of almost purely data objects, there is a hibernate like database layer that is largely encapsulated within data access objects, and a handful of service packages that are simple, self contained, and logical. The end goal of building this test suite is to move towards a continuous integration development process.
How would you go about building a test suite for such an application?
What tools would you use to make the process simpler?
Any suggestions welcome. thanks!
Start by reading Working Effectively with Legacy Code (short version here). Next I would write a couple of end-to-end smoke tests to cover the most common use cases. Here are some ideas on how to approach it: http://simpleprogrammer.com/getting-up-to-bat-series/
Then when I need to change some part of the system, I would cover it with focused unit tests (refer to the aforementioned book) and then do the change. Little by little the system - or at least the parts which change the most often - would be better covered and working with it would become easier.
I would create a few integration tests. Since they toch a lot of code, you probably will get an error when you screw up bigtime.
I wouldn't 'build a testsuite' as such, but rather before changing some part define a testset for it, and then go about changing it.
I would suggest looking into a test coverage tool (I don't code Java, so no clue what tool the best is for Java). While it does not tell you when you've tested enough, it does tell you when you tested too little ;)
Good luck!
If the project isn't already maven-ized I would do that. Also be sure to use a mocking framework like mockito. Hudson is a nice CI tool that integrates nicely with maven.
It looks like you are going to be writing both unit and functional tests, so JUnit might not be the best fit for this. Have you considered TestNG? Since you only have very few tests right now, you have the option to pick what's best for the job.
I have a couple of design/architectural questions that always come up in our shop. I said "our", as opposed to "me" personally. Some of the decisions were made and made when J2EE was first introduced so there are some bad design choices and some good.
In a web environment, how do you work with filters. When should you use J2EE filters and when shouldn't you? Is it possible to have many filters, especially if you have too much logic in them. For example, there is a lot of logic in our authentication process. If you are this user, go to this site and if not go to another one. It is difficult to debug because one URL path could end up rendering different target pages.
Property resource bundle files for replacement values in JSP files: It seems that the consensus in the Java community is to use bundle files that contain labels and titles for a jsp parsing. I can see the benefit if you are doing development with many different languages and switching the label values based on locale. But what if you aren't working with multiple languages? Should every piece of static text in a JSP file or other template file really have to be put into a property file. Once again, we run into issues with debugging where text may not show up due to misspelling with property value keys or corrupt property files. Also, we have a process where graphic designers will send us html templates and then we convert them to jsp. It seems it more confusing to then remove the static text, add a key, add the key/value in a property file, etc.
E.g. A labels.properties file may contain the Username: label. That gets replaced by some key and rendered to the user.
Unit Testing for all J2EE development - we don't encourage unit testing. Some people do but I have never worked at shop that uses extensive unit testing. Once place did and then when crunch time hit, we stopped doing unit testing and then after a while the unit tests were useless and wouldn't ever compile. Most of the development I have done has been with servers, web application development, database connectivity. I see where unit testing can be cumbersome because you need an environment to unit test against. I think unit test manifestos encourage developers not to actually connect to external sources. But it seems like a major portion of the testing should be connecting to a database and running all of the code, not just a particular unit. So that is my question, for all types of development (like you see in CRUD oriented J2EE development) should we write unit tests in all cases? And if we don't write unit tests, what other developer testing mechanisms could we use?
Edited: Here are some good resources on some of these topics.
http://www.ibm.com/developerworks/java/library/j-diag1105.html
Redirection is a simpler way to handle different pages depending on role. The filter could be used simply for authentication, to get the User object and any associated Roles into the session.
As James Black said, if you had a central controller you could obviate the need to put this logic in the filters. To do this you'd map the central controller to all urls (or all non-static urls). Then the filter passes a User and Roles to the central controller which decides where to send the user. If the user tries to access a URL he doesn't have permission for, this controller can decide what to do about it.
Most major MVC web frameworks follow this pattern, so just check them out for a better understanding of this.
I agree with James here, too - you don't have to move everything there but it can make things simpler in the future. Personally, I think you often have to trade this one off in order to work efficiently with designers. I've often put the infrastructure and logic in to make it work but then littered my templates with static text while working with designers. Finally, went back and pulled all the static text out into the external files. Sure enough, found some spelling mistakes that way!
Testing - this is the big one. In my experience, a highly disciplined test-first approach can eliminate 90% of the stress in developing these apps. But unit tests are not quite enough.
I use three kinds of tests, as indicated by the Agile community:
acceptance/functional tests - customer defines these with each requirement and we don't ship til they all pass (look at FitNesse, Selenium, Mercury)
integration tests - ensure that the logic is correct and that issues don't come up across tiers or with realistic data (look at Cactus, DBUnit, Canoo WebTest)
unit tests - both defines the usage and expectations of a class and provides assurance that breaking changes will be caught quickly (look at JUnit, TestNG)
So you see that unit testing is really for the benefit of the developers... if there are five of us working on the project, not writing unit tests leads one of two things:
an explosion of necessary communication as developers try and figure out how to use (or how somebody broke) each other's classes
no communication and increased risk due to "silos" - areas where only one developer touches the code and in which the company is entirely reliant on that developer
Even if it's just me, it's too easy to forget why I put that little piece of special case logic in the class six months ago. Then I break my own code and have to figure out how... it's a big waste of time and does nothing to reduce my stress level! Also, if you force yourself to think through (and type) the test for each significant function in your class, and figure out how to isolate any external resources so you can pass in a mock version, your design improves immeasurably. So I tend to work test-first regardless.
Arguably the most useful, but least often done, is automated acceptance testing. This is what ensures that the developers have understood what the customer was asking for. Sometimes this is left to QA, and I think that's fine, but the ideal situation is one in which these are an integral part of the development process.
The way this works is: for each requirement the test plan is turned into a script which is added to the test suite. Then you watch it fail. Then you write code to make it pass. Thus, if a coder is working on changes and is ready to check in, they have to do a clean build and run all the acceptance tests. If any fail, fix before you can check in.
"Continuous integration" is simply the process of automating this step - when anyone checks code in, a separate server checks out the code and runs all the tests. If any are broken it spams the last developer to check in until they are fixed.
I once consulted with a team that had a single tester. This guy was working through the test plans manually, all day long. When a change took place, however minor, he would have to start over. I built them a spreadsheet indicating that there were over 16 million possible paths through just a single screen, and they ponied up the $10k for Mercury Test Director in a hurry! Now he makes spreadsheets and automates the test plans that use them, so they have pretty thorough regression testing without ever-increasing QA time demands.
Once you've begun automating tests at every layer of your app (especially if you work test-first) a remarkable thing happens. Worry disappears!
So, no, it's not necessary. But if you find yourself worrying about technical debt, about the big deployment this weekend, or about whether you're going to break things while trying to quickly change to meet the suddenly-urgent customer requirements, you may want to more deeply investigate test-first development.
Filters are useful to help move logic such as is the user authenticated, to properly handle this, since you don't want this logic in every page.
Since you don't have a central controller it sounds like your filters are serving this function, which is fine, but, as you mentioned, it does make debugging harder.
This is where unit tests can come in handy, as you can test different situations, with each filter individually, then with all the filters in a chain, outside of your container, to ensure it works properly.
Unit testing does require discipline, but, if the rule is that nothing goes to QA without a unit test then it may help, and there are many tools to help generate tests so you just have to write the test. Before you debug, write or update the unit test, and show that the unit test is failing, so the problem is duplicated.
This will ensure that that error won't return, and that you fixed it, and you have updated a unit test.
For resource bundles. If you are certain you will never support another language, then as you refactor you can remove the need for the bundles, but, I think it is easier to make spelling/grammar corrections if the text is actually in one place.
Filters in general are expected to perform smaller units of functionality and filter-chaining would be used to apply the filters as needed. In your case, maybe a refactoring can help to move out some of the logic to additional filters and the redirecting logic can be somewhat centralized through a controller to be easier to debug and understand.
Resource bundles are necessary to maintain flexibility, but if you know absolutely that the site is going to be used in a single locale, then you might skip it. Maybe you can move some of the work in maintaining the bundles to the designers i.e let them have access to the resource bundles, so that you get the HTML with the keys in place.
Unit testing is much easier to implement at the beginning of a project as opposed to building it into a existing product. For existing software, you may still implement unit tests for the new features. However, it requires a certain amount of insistence from team leads and the team needs to buy into the necessity of having unit tests. Code review for unit tests helps and a decision on what parts of the code need to be absolutely covered can help developers. Tools/plugins like Coverlipse can indicate the unit testing coverage, but they tend to look at every possible code path, some of which may be trivial.
At one of my earlier projects, unit tests were just compulsory and unit tests would be automatically kicked off after each check-in. However, this was not Test-driven development, as the tests were mostly written after the small chunks of code were written. TDD can result in developers writing code to just work with the unit tests and as a result, developers can lose the big picture of the component they are developing.
In a web environment, how do you work with filters. When should you use J2EE filters and when shouldn't you?
Filters are meant to steer/modify/intercept the actual requests/responses/sessions. For example: setting the request encoding, determining the logged-in user, wrapping/replacing the request or response, determining which servlet it should forward the request to, and so on.
To control the actual user input (parameters) and output (the results and the destination) and to execute actual business logic, you should use a servlet.
Property resource bundle files for replacement values in JSP files.
If you don't do i18n, just don't use them. But if you ever grow and the customer/users want i18n, then you'll be happy that you're already prepared. And not only that, it also simplifies the use of a CMS to edit the content by just using the java.util.Properties API.
Unit Testing for all J2EE development
JUnit can take care about it. You can also consider to "officially" do user tests only. Create several use cases and test it.