Achieving a 100% code coverage isn't necessarily the victory objective here, for two reasons, first testing one case of each methods does not permit us to say that we are potentially bug free. At the same time, testing all cases of a method can be quite time consuming, rendering the tests too expensive for the company. So what we need to do is fine the right amount or amounts (depending on the project) of tests that we need to improve our quality of work while staying cost-efficient.
In addition to the unit tests it is necessary to regularly test the whole of an application with integration tests.
To do this, there are specialized products of continuous integration which will : retrieve the source code of a component which was just commited on a repository recompile that source code relaunch unit tests package the compile code of the component in an archive deploye it on a specific test environment launch integration tests of the aggregate of the components pass on messages and statistics to the developer concerned (and other people indicated in settings) generate and stock a new version of the whole application if the tests went well. Most of the continuous integration environments use MAVEN or ANT as fundamental technologies
Examples of Metrics : - Test Code coverage - Successful Build Rate - Build Repair Rate (It indicates the time taken to repair a failed build) - % of code duplicated - Lint checks - Coding standards violations - Build compilation time - Cyclic Complexity Number (CCN measures how many paths there are through a particular piece of code) - Dead code
What we want to achieve with Continuous Delivery is, as soon as some code is ready, to automatically put it through Unit Tests then integration and acceptance tests, so that at any moment we want to, we can deploy to production and issue a release of the application.
As we see it on this UML diagram, the key is to implement in our workflow an automated loop that causes us to correct our code the sooner possible until it is ready to put directly to production, thus increasing our speed to produce a qualitative product to our customers.
Now we spend a lot of time testing manually after programming a feature, which cost the company money, and demotivate the developers. There is another factor that arise with this method of working, the risk, because as humans we can not guaranty that the tests will always be 100% thorough and accurate. Risks of what exactly ? Imagine a case where we discover one bug at the last stages of the process, it'll surely be much more complicated to fix than at the moment it was introduced. What we need is to speed up the whole process while improving the quality, and I believe we can do it with the concepts I introduced to you today. * Study made in 2002 by the National Institute of Standards and Technology (NIST).
Testing & continuous delivery
Introduction to good practices insoftware developmentTesting &Continuous Delivery 101Nelson Melina
What is Unit Testing ?● An Unit is smallest testable part of sourcecode.● It Can be an entire interface or just a method(OOP).● Unit Testing isolates parts of a software andverify that each parts behave as intended.
What are the benefits of Unit Testing?● You will find potential problems at the earliesttime possible.● You can refactor code without the fear orregression issues.● The tests serve as a design documentationof how a unit is supposed to work.
What are the limits of Unit Testing ?● They only show the presence or absence ofparticular errors● For every line of code written, programmersoften need 3 to 5 lines of test code.● Nondeterministic and multiple threadsalgorithms can not be easily tested.● Rigorous discipline is needed throughout thesoftware development process.
What are the most common tools ofUnit Testing ?● JUnit (framework)● DBUnit (extension of JUnit)● Mock objects frameworks
Mock Objects● They are simulated objects that mimic the behavior ofreal objects in controlled ways● We need to use them when an object :– returns non-deterministic results.– has states that are difficult to reproduce (e.g., a networkerror).– is slow (e.g., a database).– does not yet exist or may change behavior.– would have to include information or methods only fortesting.
What is Integration Testing ?● Occurs after Unit Testing and beforevalidation testing.● Combination of individual software modulesthat will be tested as a group.
The next step towards completeefficiency is Continuous Integration
RepositoryUnit tests ACode ACode BCode CUnit tests BUnit tests CUnit Tests A, B, C& Integration Tests(A + B + C)Module A (Wallet)Module B (Widget)Module C (MAV)Feedbacks (Alerts,Information, Errors orStatuses) via email towhom is concerned.Continuous Integration Server(Hudson)Is the aggregatebehaving well ?
Here are the key principles of CI● Maintain a code repository.●Automate the build.●Make the build self-testing.●Everyone commits every day.● Every commit should be built.●Keep the build fast.●Test in a clone of the production environment.●Make it easy to get the latest deliverables.● Everyone can see the results of the latest build.●Automate deployment.
Advantages of ContinuousIntegration● When unit tests fail, developers can revert to a bugfree state.● Integration problems and problematic changes arecontinuously detected and fixed.● Immediate feedback to developers.● Frequent code commits pushes developers to createmodular and less complex code.● Metrics generated from automated testing and CI.
The final goal is to achieveContinuous Delivery
Why would we change our way ofworking ?● Reduce current and future costs– Without an automated process, developers lose a great amountof time testing manually the features they program.– The latter we find a bug, the more expensive it is to fix.*● Reduce risks– It is impossible to guaranty that all manually executed test willalways be thorough and accurate.