Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Testing & continuous delivery
1. Introduction to good practices in
software development
Testing &
Continuous Delivery 101
Nelson Melina
2. What is Unit Testing ?
● An Unit is smallest testable part of source
code.
● It Can be an entire interface or just a method
(OOP).
● Unit Testing isolates parts of a software and
verify that each parts behave as intended.
3. What are the benefits of Unit Testing
?
● You will find potential problems at the earliest
time possible.
● You can refactor code without the fear or
regression issues.
● The tests serve as a design documentation
of how a unit is supposed to work.
4. What are the limits of Unit Testing ?
● They only show the presence or absence of
particular errors
● For every line of code written, programmers
often need 3 to 5 lines of test code.
● Nondeterministic and multiple threads
algorithms can not be easily tested.
● Rigorous discipline is needed throughout the
software development process.
5. What are the most common tools of
Unit Testing ?
● JUnit (framework)
● DBUnit (extension of JUnit)
● Mock objects frameworks
6. Mock Objects
● They are simulated objects that mimic the behavior of
real 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 network
error).
– is slow (e.g., a database).
– does not yet exist or may change behavior.
– would have to include information or methods only for
testing.
7. What is Integration Testing ?
● Occurs after Unit Testing and before
validation testing.
● Combination of individual software modules
that will be tested as a group.
8. The next step towards complete
efficiency is Continuous Integration
9. Repository
Unit tests A
Code A
Code B
Code C
Unit tests B
Unit tests C
Unit Tests A, B, C
& Integration Tests
(A + B + C)
Module A (Wallet)
Module B (Widget)
Module C (MAV)
Feedbacks (Alerts,
Information, Errors or
Statuses) via email to
whom is concerned.
Continuous Integration Server
(Hudson)
Is the aggregate
behaving well ?
10. 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.
11. Advantages of Continuous
Integration
● When unit tests fail, developers can revert to a bug
free state.
● Integration problems and problematic changes are
continuously detected and fixed.
● Immediate feedback to developers.
● Frequent code commits pushes developers to create
modular and less complex code.
● Metrics generated from automated testing and CI.
14. Why would we change our way of
working ?
● Reduce current and future costs
– Without an automated process, developers lose a great amount
of 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 will
always be thorough and accurate.
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).
