More on test coverage
This week I read two blogs circling around the test coverage topic. The first one insists that 100% test coverage may sometimes give you false idea about your code quality. The idea is that if you think that with 100% coverage you are done and safe, then you are wrong. You have to surely go to the next level – manual or automatic integration tests. Such tests that test your code the way that it will be really executed and not the way that you think it will be executed (which you express in the unit tests).
So, do not fear, write test, be cool (or groovy? :-)) and don’t worry about the rest.
This is an article for those of you who are aware and use Spring Web Flow. It is a framework that gives you the opportunity to easily build wizard-like web application.
The author of the IBM developerWorks article focuses on the persistence mechanisms in a Web Flow application. Basically during a typical application the user is navigating through several pages and views, each of which presents different data, which needs to be stored somehow during the flow. However usually the user input is not committed in the database on each click of a Next button, but rather at the end, when the whole process is finished.
So the author shows you how you can use different techniques of controlling the transactions in both the atomic and non-atomic web flows (the latter commits a portion of the data on each transition). It was interesting for a person like me (I have a common knowledge on Spring, but nothing on Spring Web Flow). I hope that there are readers with interest and experience in the latter. You will surely appreciate and find the article useful.
This is a very interesting introductory article explaining how to use the so called flash scope in JSF 2.0. The scopes in the Java EE 6 world are coming from the Contexts and dependency injection technology. They are basically concerning how long an object is managed by the container. The most usual scope is the request scope. The problem there is that after the request is over (it usually happens on each redirect to another page), the data submitted at the previous request is lost. However, sometimes you need that data and you don’t want to use the session for storing the data that has to survive between the different requests. If you just need you data to be alive in the next request, then you put it in the flash scope.
How to do that and how to get it from there? Go on and read the article and you’ll find out. 🙂
Most the application developed today (no matter whether they do web or desktop apps) ask the user to enter some kind of data. This automatically implies that the user input has to be validated against defined rules (or constraints) like “not null”, “at least 10 characters long”, “at most 100 characters long”, etc. The different [web application] frameworks have provided different approaches for data validation.
Before Hibernate validator was born, all the existing validation libraries were bound to a certain layer. Some of them did the validation in the presentation layer, others in the business layer and even some application rely on the validations done by the database engine.
With Hibernate validator the developers are free to put the validation code wherever they like. The only thing they need to do before that is to create the metadata (what are the validation constraints) in the domain objects that will be eventually validated. And leave the rest to the framework.
Now, the article presented hereby gives you a quick start to using the Hibernate validator library, which above all appears to be the reference application for the bean validation specification.