Services, practices and tools that should exist in any software development house / department - Part 2.

Jun 23, 2011 java english
Share on:

We will continue to list and elaborate on simple steps towards shaping up a proper development environment. In the first part we have gone through 3 basic tools 1) Code Repository 2) Issue Tracker 3) Wiki (Part 1). Let's move on.

  1. Build Server (Continuous Integration): One of the simplest and accurate descriptions on the definition of continuous integration is given by Martin Fowler

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible" .Simple as that. A builder & integration server is a software service (usually a web application hosted on an app server) that will offer functionality like automatic and regular builds of the code saved in the repository, run tests or other quality plugins and produce reports daily regarding the 'health of the code. Team members will be able to monitor and get notifications about exceptional cases of errors in each aspect of the integration life cycle for example, build errors, number of tests failing after a specific update, quality metrics after analyzing the code. Wikipedia has a quite decent article on the subject.

There are some basic concerns around selecting a continuous integration /build server.

  • (Type**$$**) Which one of them? We are lucky enough (yet again) to point that there is a variety of potential solutions both commercial and open source. When it comes to open source you will see services like Hudson / Jenkins / CruiseControl / Continuum. I have worked with most of them in different companies and I would say that all of them keep their promise on providing basic functionality. You will need to examine the different features / release and update cycles of the technology / and integration with other systems - in order to make your choice. When it comes to commercial packages there is a again a large set of available solutions- some of them would be TeamCity / Bamboo etc. You will find lots of blog posts around the net listing potential solutions for example this one.
  • (Backup) As already elaborated many times in the previous post.After installing the service and using it, we should be aware that we need to setup a backup strategy and procedure, usually assigning this task to any of our administrators.
  • (People) An integration server is a component that works for the team, the main thing you want to ensure is that it works properly and that people around the software development life cycle pay attention to it's work results ( notifications, reports and monitoring facilities).Integrating continuous integration into your software development process you make a step towards being proactive on ensuring software quality. It is something that the management should evaluate carefully.

  1. Testing (tools and practices) : Testing is one of the most important activities during software development. Eventually many people (even today) consider it as waste of resources and time. There are several things that we can do in order to easy our pain on these things + change our attitude towards this important (quality wise) activity.

  2. Practice Testing should be supported by the project management & upper layers. Testing does not start on the technical level when it comes to _actually doing it'.The testing phase starts when it is slowly being properly integrated in the project plan, in the attitude of the software development process, in the trust that the managers and PMs will put on it. There is no - magic button - called now we do testing - in a any software development team. I have seen the following mistakes through out my carreer.

  3. Project and task estimates do not include time (in a pragmatic manner) for proper testing either unit testing ( done by developers mainly) or functional testing (done by a testing team - if there is one). By not assigning time, the developers are forced to tackle the implementation and testing of their tasks into the same time slot- resulting to skipping the less urgent sub task (the test). You can not easily persuade a project management or a budget manager of a software project to take into account testing as an activity. The results are obvious after the first releases or after the service/ product goes into production resulting to immediate switch from extreme programming to extreme testing on a problematic solution (something that is again completely wrong - see above the magic button effect).

  4. Developers get lazy: Eventually we can not blame the _managers all the time. Software developers get lazy from times to times since they consider as well testing - as a second class citizen on their task list. Eventually this attitude should be enforced by senior management and by the overall software development practice followed on each department. For example when you introduce automated testing through the execution of tests on a continuous integration server - and you monitor the areas of the code where the developers have indeed performed test - you may apply the correct change of attitude to those not paying attention. Some times the complexity of the software and it's design acts like a another reason of a developer moaning (I can not test) and this something that senior developers and architects should pay attention and modify as soon as possible potential parts of the code - make it modular and use the appropriate technologies in order to help/automate/ and encourage on the developer level the testing practice.

  5. The tools There several tools and practices that can be applied in order to implement and ease the work on testing. I will provide a short list on things I have seen in my java related career up until now.You may find many other links here for other programming languages or frameworks, here.

  6. Developer frameworks and tools

  7. JUnit (Unit testing)

  8. TestNG (Unit testing)

  9. JMock (mocking techniques)

  10. Mockito

  11. Ejb3Unit (or standalone containers nowdays)

  12. XMLUnit

  13. HTMLUnit

  14. Web testing /automating functional testing

  15. Selenium (web)

  16. Sahi

  17. JMeter (Performance & Testing)

  18. Code Coverage : Up until now we have talked about basic steps towards integrating testing into our project management and every day coding. How we will be able to tell if we are on the right track? How good or how much are we testing? What about quality constraints applied by potential customers (example: we demand 80% of the business code to be covered by tests or similar requests). This is where code coverage as a practice kick in. It is tool to monitor and efficiently fine tune our testing activities. There are certain tools and frameworks that analyze our source and test source trees and provide metrics regarding the amount of real business being tested. In the Java world you may see tools like :

  19. EMMA

  20. Cobertura

  21. Clover (commercial)

That is all for this second part. I don't want to make the posts huge (they already are). Bare in mind that I expect senior and experienced developers/ architects to already have all the above in place or know about them. The main purpose of these posts is to act a reference point starting point. I encourage you to post comments and provide your own alternatives on the things mentioned above. See you on part 3.