In the previous article we explored unit tests as the first and fastest set of tests we should run. Now it’s time to see whether our unit tests provide enough code coverage.
Unit tests by themselves do not provide enough confidence unless we know that they cover significant code coverage. Having all tests successful while, for example, covering only 15% of the code cannot provide enough trust.
Mature teams might not need to measure code coverage. They might know from experience that their unit tests are covering as much code as the project they’re working on needs. Teams like that tend to have years of practice with Test-driven development (TDD). However, for the majority of us, tools that measure the coverage are very indeed useful addition to our tool-belt. Continue reading →
I’ve been working with BDD for years and felt that it needed an application that would facilitate the Behaviour-driven development work-flow. It would need to be made in a away that anyone can use it. By anyone I mean people with or without technical skills. Coders, testers, analysts, managers, business, etc. In that spirit, I started working on BDD Assistant. It is an open source application that can be used to create, manage and run BDD stories.
Now I feel that it is finally ready to go public. The application is far from being finished but there is enough done for the community to see what it’s all about. More information can be found in the BDD Assistant site. Latest release can be downloaded from our GitHub repo. Live demo (with some features disabled due to hosting limitations) can be seen from the BDD Assistant demo. Continue reading →
In the previous article we explored static analysis as one of the first steps in Continuous Delivery. Our journey will continue with unit tests.
Unit tests are probably the most important part of Continuous Delivery. While unit tests cannot substitute integration and functional tests, they are very easy to write and should be very fast to execute. As any other type of tests, each unit test should be independent of each other. What differentiates unit from other types of tests (integration, functional) is the scope. Each unit test should verify only a single unit of code (method, class, etc). Main benefit of unit tests are that they can find problems early due to their speed of execution. When ease of writing is combined with very short execution time it is no wonder that unit test often represent biggest part of automated tests. Continue reading →
The previous article CI Tools Setup ended with Jenkins up and running waiting for us to use it. Travis, on the other hand, was left aside and soon we’ll see why.
In this article we’ll explore static analysis as the first type of tasks that we should do in our delivery pipeline. Since that is our starting point, let’s go through the brief explanation. Continue reading →
This is the first article of the Continuous Integration, Delivery and Deployment series. We’ll start out journey with brief explanation of Continuous Delivery. After short exploration of some of the tools used today, we’ll move towards the flow (from setting up brand new environment and getting the code from the repository to the creation of fully tested and verified distribution). Each section will present different approaches, compare different tools and, finally, provide some hand-on examples. After the flow, we’ll explore changes required in the development life cycle. Finally, we’ll dive into last steps required for the transition from Continuous Integration towards Continuous Delivery and Deployment.
You got that great idea for an application that will be a huge success. High level feature set and design is done and you are ready to start bashing the code. Before you do, you might go through a checklist of tasks that should be done before the coding starts.
There are three things that I consider as prerequisites of every project (apart from knowing what the high level scope of the project is).
Some kind of a project management tool or a task tracker
Version Control System (VCS)
Continuous Integration (CI) framework with jobs for each phase from the build to deployment
I, for one, am often inclined to simply start bashing the code. However, that temptation should be avoided in favor of a better and more stable project development. Continue reading →