Maven and TestNG
Yesterday, while browsing through the World Wide Web, I read a couple of articles. The first one talked about Maven. The second one talked about The Top 12 Productivity Killers in Development Methodologies. I was captivated by Maven and intrigued by the second that I decided to blog about Maven and TestNG.
What is Maven? Well, I can quote what is written on its web site:
Although this might seem a simple functionality, if you ever worked with huge projects, specially if they are component oriented projects, you can see the benefit. Imagine that you have a tool that automatically handles your dependencies, builds them, ensures that no dependency is built twice and has all the phases that you need, that is, compilation, testing, packaging, reporting and, for those that go the extra mile, source code generation, etc., etc.
Imagine Ant on steroids: you have a real tool that manages projects described as an XML file, unlike Ant where the goal is to have a build file that is an XML file. The potentialities are even greater then with Ant. I'm saying this and I had to develop a component building system on top of Ant that handled dependencies, ensure that components were built only once, ran unit tests, build test and coverage reports, etc., etc. This was hard, it even has some python scripts in it. With Maven this would be a lot easier.
But lets put Maven at the side for a moment and talk about the other article: the one about The 12 Productivity Killers in a Development Environment. Many of these killers hit the Development Environment in my company so there was nothing new for me on those issues, but there was one strategy that I wasn't aware of. Fact 6 on Page 2 of the article mentioned the idea of having several testing layers.
The idea is to have several defense strategies that warn you the soonest possible of any issue in your project. This can be way before anyone actually testing it for real. Here the TestNG software comes in. The TestNG is like an extended version of JUnit. Amongst many other features it allows you to define a category for your test. This way your unit tests may categories such as: consistency tests (that verify that the component works well on its on), integration tests (that checks that multiple components work well together), system tests (that verify that the system is working well with all components together), functional tests and so on. Or you can separate the tests in fast and slow tests, running the fast ones first to ensure that the production stops on a killer issue. You can even have a category called "Regression Tests" that are ran always as last to ensure that no bug is resurrected.
The problem with any new Methodology is the usual Aversion to Change you find when you propose it. It seems that everybody has been doing it the old way for too long and they don't want to learn a new way. Facts are that as a team grows its methodologies and the way work is carried out needs to be adjusted and sometimes new methodologies are in order.
For instance, where I work we used to be 3 programmers in the team. With a low number of programmers source code access isn't a problem. In fact, if the programmers have some sense you won't get into problems. Now we are almost 10 programmers. What happens? Well, if you are in a project that has multiple versions on the field that need to be supported and you need to make patches for, with also multiple new versions and customer dedicated projects with different features in development... Well, if you don't have a tight control over what gets into a release you are in serious trouble. What could happen? Well, you might need to release a patch on a certain branch, but someone has already checked in some changes in that branch that shouldn't go in the patch. At the same time the changes in the branch should continuously be merged to another branch where development of the future versions is taking place. This is hard to do, specially if you don't control the access to the source code!
I believe a better way is to have several branches for development of new features or bug corrections and a main branch to be used to build deliveries. The idea is that every time you make a delivery you create a branch that will be used to build patches of that version. Over that branch, other branches will be created for the developers to use when correcting bugs or adding features. Depending on the project's plan, when the time comes to make a new delivery, it is a matter of merging all the branches of the features and/or bug corrections to include into the branch that is being used for the new delivery, be it the branch to produce a patch or a new version of the product. This not only tightens the control of the source code but it also allows you to know what exactly changed between one version and another. This information is extremely important for the testing teem: it allows them to know what features or components changed and need to be tested in more detail.
This, I believe, should lead to more quality control in a Software Development Project. But to make it clearer I would probably do better in writing an article about it...
What is Maven? Well, I can quote what is written on its web site:
Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.What does this mean? Well, it means that you declare your projects dependencies and Maven will take care of all the work, even if it involves downloading the dependencies from the Web.
Although this might seem a simple functionality, if you ever worked with huge projects, specially if they are component oriented projects, you can see the benefit. Imagine that you have a tool that automatically handles your dependencies, builds them, ensures that no dependency is built twice and has all the phases that you need, that is, compilation, testing, packaging, reporting and, for those that go the extra mile, source code generation, etc., etc.
Imagine Ant on steroids: you have a real tool that manages projects described as an XML file, unlike Ant where the goal is to have a build file that is an XML file. The potentialities are even greater then with Ant. I'm saying this and I had to develop a component building system on top of Ant that handled dependencies, ensure that components were built only once, ran unit tests, build test and coverage reports, etc., etc. This was hard, it even has some python scripts in it. With Maven this would be a lot easier.
But lets put Maven at the side for a moment and talk about the other article: the one about The 12 Productivity Killers in a Development Environment. Many of these killers hit the Development Environment in my company so there was nothing new for me on those issues, but there was one strategy that I wasn't aware of. Fact 6 on Page 2 of the article mentioned the idea of having several testing layers.
The idea is to have several defense strategies that warn you the soonest possible of any issue in your project. This can be way before anyone actually testing it for real. Here the TestNG software comes in. The TestNG is like an extended version of JUnit. Amongst many other features it allows you to define a category for your test. This way your unit tests may categories such as: consistency tests (that verify that the component works well on its on), integration tests (that checks that multiple components work well together), system tests (that verify that the system is working well with all components together), functional tests and so on. Or you can separate the tests in fast and slow tests, running the fast ones first to ensure that the production stops on a killer issue. You can even have a category called "Regression Tests" that are ran always as last to ensure that no bug is resurrected.
The problem with any new Methodology is the usual Aversion to Change you find when you propose it. It seems that everybody has been doing it the old way for too long and they don't want to learn a new way. Facts are that as a team grows its methodologies and the way work is carried out needs to be adjusted and sometimes new methodologies are in order.
For instance, where I work we used to be 3 programmers in the team. With a low number of programmers source code access isn't a problem. In fact, if the programmers have some sense you won't get into problems. Now we are almost 10 programmers. What happens? Well, if you are in a project that has multiple versions on the field that need to be supported and you need to make patches for, with also multiple new versions and customer dedicated projects with different features in development... Well, if you don't have a tight control over what gets into a release you are in serious trouble. What could happen? Well, you might need to release a patch on a certain branch, but someone has already checked in some changes in that branch that shouldn't go in the patch. At the same time the changes in the branch should continuously be merged to another branch where development of the future versions is taking place. This is hard to do, specially if you don't control the access to the source code!
I believe a better way is to have several branches for development of new features or bug corrections and a main branch to be used to build deliveries. The idea is that every time you make a delivery you create a branch that will be used to build patches of that version. Over that branch, other branches will be created for the developers to use when correcting bugs or adding features. Depending on the project's plan, when the time comes to make a new delivery, it is a matter of merging all the branches of the features and/or bug corrections to include into the branch that is being used for the new delivery, be it the branch to produce a patch or a new version of the product. This not only tightens the control of the source code but it also allows you to know what exactly changed between one version and another. This information is extremely important for the testing teem: it allows them to know what features or components changed and need to be tested in more detail.
This, I believe, should lead to more quality control in a Software Development Project. But to make it clearer I would probably do better in writing an article about it...
Comments
Post a Comment