Tag Archives: Best Practices

Spring Config File Best Practices

March 27, 2012   admin   1 Comment

Spring based projects revolve around Spring configuration XMLs. As project goes through development phase, with more and more code getting generated, it leads to frequent updating of Spring config XMLs, and it becomes nightmare to manage these files. Following spring config file guidelines or spring config file best practices would help to manage these files well and avoid merging issues, high maintenance cost etc.

Read More

Revised Jsp Best Practices

November 17, 2009   admin   No comments

JSPs are an integral part of a web application. If jsps are not coded properly, then it becomes a most unorganized piece of code. You must have seen huge jsps, which end up as a source of defects, and asking you to change them many times. Maintaining such code becomes a very expensive activity. Also it impacts stability of entire application. Following few simple practices can change working on jsp into a happy activity.

1. Reuse Common HTML

There are two main advantages of it. First is – you are maximising reuse and improving productivity. Second is – you are keeping main jsp as small as possible to maintain them better. Small jsp will also help to easily debug. Better way of reusing code is moving the html code to another jsp, and including that jsp at appropriate place. Mostly header and footer information can be common which can be included in each Jsp. You can identify such reusable html code snippets in your jsps, and seperate those out.

2. Separate Javascript

First good practice would be reducing the java script as much as possible. But under un-avoidable circumstances move it to javascript (js) files and including those in all required jsps. Also, grouping those javascript functions according to functionality is a good idea, this will reduce the amount of javascript you include in each page. Also think of including javascript at the bottom of page instead of top to improve performance.

3. StyleSheets can be Used to Define Themes

This is another component which can be separated out and reused. But there are broader applications of stylesheets. Stylesheets with images and other static contents, contribute to look and feel of a site/all html pages. Now providing theme based styling of site is becoming popular. If you can build some level of theme based stylesheet application some how, then it will be good. Few web tier frameworks (Spring MVC, etc.) offer the feature of theme based look and feel. Depending on other aspects, you can choose one of those. At least you can separate code in stylesheet and include in all jsp pages.

4. Maximise Use of Ready Custom Tags

Select appropriate freely available custom tag library. If possible check if there are any defects in those libraries with respect to the technology set you are selecting. Also see which one provides you maximum number of required features. JSTL tag lib is a mostly used alternative. Also, you can opt for the libraries provided by the selected framework. Struts comes with a rich tag library, which supports many common application features and also advanced features like AJAX.

5. Identify and Build Application Custom Tag Library

This makes life easy of all the developers of application. You put early effort and identify the tag libraries you need in your application. Build those and make available at the time of coding start. This improves productivity considerably and stops all developers from messing up the code in their own style.

6. Use Javabean Based Client Server Data Transfer

Struts, Spring MVC, Tapestry, and JSF provide MVC based frameworks, which enable automatic population of the client submitted data in the defined java beans. This means you don’t need to retrieve all atributes separately from http request in servlet. You can implement your own mechanism for this, if you are not using any framework.

7. Select Appropriate Web-tier Framework

This is clearly a strategic decision to go for a ready framework or not. How your organization permits and how your requirements are satisfied, this will determine which framework you select from Struts, Sprint MVC, Tapestry, JSF, etc. and the supporting frameworks like Velocity, Tiles etc. Identify the benefits according to your needs and select appropriate one. Secondly, also check the support availability for the selected framework.

8. Enable Client Side Caching of Static Contents

Here we come to something related to performance. You may have heavy images and other static contents embedded in your jsp.You may not be changing these everytime the page is loaded. You can enable caching of these items so that the end user gets feel of quick loading of page. Also see how your server’s web container supports this.

9. Define Object Scope Correctly

It is possible that unwanted objects are loitering jsp default objects (session, page, request etc.) un-necessarily, and you get wrong results due to garbage objects. Hence identify scope of objects correctly, and place those in appropriate scope object. This will ensure cleaning of those objects in due time.

10. Identify and Design Special Handling of Browser Buttons

Some times you need to take care of browser buttons separately. It can be refresh button, back button or even browser close button, finalize the requirement and implement it at common place so that all jsp pages can use it.

11. Optimize Amount of Data Getting Displayed

This has to do with identifying and negotiating requirement at right time. If you want the page to be loaded very quickly, then trade off against the amount of data you load on the page. Otherwise, redesiging page after performance testing cycle will be a huge effort.

12. Use Jsp Comment Over HTML Comment

You may not want to send comment data to client. Mostly comments are for developer understanding from maintainability point of view. Hence you don’t want to increase the amount of data getting sent to client side. Hence use jsp comments, which do not get included in the html getting sent to client.

<!– HTML –>
<%– JSP does not go to client to clog network –%>

13. Set Page Caching and Expiry as Required

If you want your page to be loaded everytime a fresh, then set the caching and page expiry meta data directives correctly. Also consider the static data caching point above while doing this.

Read More

Important Practical Tips for JUnit Users

October 21, 2009   admin   No comments

Test driven development, automated testing, open source unit testing frameworks, mocking test data, etc. etc. have been buzzing around us for past few years. Most of the Java developers must have used JUnit to write unit test cases at least once. Below are some of the points that I found important while writing JUnit test cases in application development. You can call these as tips, best practices, or whatever you like.

  1. Externalize Data: Move test data out of test classes. You can have helper classes to support, or you can code data loading mechanism in set up methods. Test data can be externalized to text files, xml files, excel files, and database tables or any other fancy way you think.
  2. Setup at the Beginning and Destroy at the End: Load required test data at the beginning of test suite execution. You can delay test data loading as late as to the setup method of individual test classes. Also, it is good to remove the test data when it is no more needed.
  3. Unit Testing should Target Development Database: Database getting used for JUnit test cases should be development database instead of any other (higher) environment databases. JUnit test suites are run during build process, hence instead of going to test/acceptance test environments, target development database. You can pollute it without fear.
  4. Assert Success and Failure Scenarios Both: Test step execution will lead to some desired or even any un-desired results. Assert using JUnit provided assertion techniques, and decide success or failure of test.
  5. Test Coverage should be enough: Ideally you should have 100% test coverage for all classes. But practically, you can exclude data classes (having only getters and setters) or write a test generator utility that reduces effort getting spent on these classes. For important functional classes, the test coverage should be more than 90%, and overall test coverage can fall to 80%. It can be more stringent than this depending on accuracy level required. But usually 80% of testing is enough to make system satisfactorily stable for further (integration/system) testing.
  6. Use JUnit for Unit testing and not for System testing: Usual mistake that is observed is you tend to test application layers using JUnit. i.e. Servlet test case also tests integration till database. This is not unit testing. This leads to un-necessary coupling, and makes test cases un-maintainable in future.
  7. Enough Logging: Logging helps to monitor progress of test execution, and also helps to debug in case of any failure. Add enough debug statements (may be using the same logging framework as that of the main code).
  8. Automate Test Suite Execution: Using build tools like Ant or Maven, you can automate the test execution. You may need to write small amount of code for this but it saves a lot of pain later. One command and all tests are run. This also does not make developers feel burden of test execution every time.
  9. Reduce Memory Footprint: Loading too much data is common cause of large memory footprint. Load only required data. Large memory footprint slows down the test execution. You can also look at nullifying heavy classes in finally blocks or in exception blocks.
  10. Coupling Amongst Test Classes should be Minimized: Unit nature of test classes should be preserved. Many times we end up reusing test classes leading to un-maintainable test suites due to highly coupled test classes.
  11. Generate Summary Report: At the end of test run, generate a good summary report that can help to know exact status of unit test run. Coverage monitoring tools usually provide good reports, you can use those. It is also possible to dig these reports to finer levels.
  12. Update Test Cases Along with Main Code Changes: There is always a fear of test suite becoming outdated. Development team continues to work in pressure modifying the main classes to meet timelines, leaving test suites mapping to old versions of main classes. To make test run succeed, you comment outdated test cases or assert them falsely. Both are not good for the very purpose of having unit test cases automated. Hence it is good habit to have test cases updated as a part of build.
  13. Package Test Cases and Main Classes Separately: Having both main and test packages separately makes it easy to maintain test cases. Also it helps in build tool handling. In short, this is cleaner approach.
  14. Try to Clean up Database after Test Run: If you are committing anything in database during test run, then try to bring the database to original state. Sometimes it is ok to leave DB like that, because any way you are using development database.
  15. Include Test Cases in Application Build: Make test case execution part of build command, this will make it mandatory for everybody to run the test cases and keep those updated regularly. If required you can give feature of skipping the test run.
Read More
Powered by WordPress | Designed by: seo service | Thanks to seo company, web designers and internet marketing company