We recently did an interview on wedotdd.com on how we practice TDD. We decided to share our answers also in our blog, keep on reading if you want to know more!
An agile software developer at XPeppers has on average four years worth of experience in agile methodologies and has therefore grown a skillset that ranges from Clean Code and Refactoring to Test-Driven Development. Our software developers spend most of their work hours crafting customer ideas into great software.
All team members at XPeppers focus on their continuous improvement by investing time in studying new technologies and paradigms, doing katas and setting up coding dojos and presentations.
Each developer who joins our team has a study path to follow and has a mentor that helps them learn all the things we value most at XPeppers, among which you can obviously find TDD.
We know that TDD can be learnt only with practice and therefore we suggest katas and organise internal coding dojo during our study time to both improve our skills and share ideas. We try to teach our developers TDD "on the field" by pairing up developers who are less experienced on TDD with our XP coaches.
Our developers quickly get that TDD has a huge impact on the quality of the code they craft and easily become engaged with it. With time they understand that tests are not only a good way to avoid regressions but also a great tool to improve code design.
At XPeppers we try to work on uniformed pairing stations that run similar software. In addition to this, we’ve noticed that large desks with big monitors encourage a more natural role and keyboard switch.
During our pair sessions we do talk a lot (hence we’re italian :P) and collaborate in order to make better design decisions and write better code in general.
Another practice we sometimes do is to pair (on site and remote) with a member of customer's team to enhance domain knowledge and share development best practices.
At XPeppers every team is shaped according to customer needs and follows a project from the beginning until its delivery. Its members however, might be adjusted based on iterations and workload whereas the team ideally is cross-functional by nature. In this way we are able to enhance our focus on a specific product and share experiences throughout the team on a project based manner.
Every month we update our projects portfolio board to both assure everyone is allocated and to have a more long term view of ongoing projects.
In some of our projects we have a QA person that tests the user stories when they are available on a production-like environment. Usually they try to replicate the requirements written in the back of the user story.
In some other projects we write an automated user acceptance test and we have a set of UAT that proves that our software works as intended (or expected) by the customer.
We have huge experience on financial applications: we built both Mobile Payment Apps for iOS and Android and backend payment gateways for some of the biggest players in Italy.
We are confident with API development (lately we are working extensively with Serverless Architectures).
The XPeppers team has many other successful case studies with different customers among with you can find famous newspapers, networking companies and public institutions.
Every XPeppers team has its Product Owner which talks directly with the customer to collect the requirements and other information such as some priorities including scope, time and quality. In this way the PO can better understand the real customer needs.
Then the team takes part to a KickOff meeting in order to update all the team members on projects goals, the expected results, the timing and the process.
The whole team defines the priority for each story to minimize the time spent to have a working software that can be tried and approved by the customer.
A story complexity is estimated in points based on the team experience or on a spike made before. The points are assigned following the Fibonacci scale starting from the simplest story.
We use a physical Kanban-board every time is possible. If a team is distributed we have a virtual board, even if we often reply it in a physical format for visualisation convenience.
We schedule meetings with the customer every 1 or 2 weeks to do a demo of the software and plan which stories to include in the following iteration.
In XPeppers we adopt many XP practices like Pair Programming, TDD, Code Review. We rely on the type of customer/project to choose the practices that help us to enhance the quality of the project, the development process and the relation with the customer.
A typical developer machine at XPeppers is a MacBook Pro 13' or a Dell XPS 13'. We have an IDE to work with languages like Java or C# and an editor like vim, emacs or atom.
We follow the Agile Manifesto, so we value people more than tools: this is why we try to decide as a team which configuration is best suited for a given project.
We use to write different kind of tests based on the project context. Basically, using TDD, we happen to leave a trail of tests behind us, which are going to be the core of our test suite. We tend to cover the code strategically: the most important or risky is the feature, the more tests we write for that part of code. We also write integration tests, to verify the behaviour of the system (or one of its part) as a whole. Those tests are all written by developers as part of their day-to-day work. We then also write Acceptance Tests, which we use to discuss and clarify features with customers. Those are the main type of tests we write.
Just to give a concrete example, those are some numbers taken for two big-sized projects:
- 2,500 Unit tests, running in about 30-40 seconds
- 200 Integration tests, running in about 19-20 minutes
- 250 Acceptance tests, written as Cucumber scenario tests, running in about 12-18 minutes against a production-like deployed application
- 2,308 Unit tests, running in about 10-15 seconds
- 556 Integration tests, running in about 6 minutes
- 502 Acceptance tests, running in about 17 minutes against a production-like deployed application
Depending on the project context, we may decide to write also other type of tests, mainly smoke tests and stress tests.
As a consulting company, we don't have a team style or specific approach to TDD. We'd like to see TDD as an effective practice to build working software. We try to choose the approach that best fit particular situation, team or product.
When we are working with an external team, like customers who are approaching TDD for the first time, we like to keep a smooth and very strict rhythm so that people can appreciate, learn and better understand the practice. From the other hand, we tend to shift to a faster and less strict approach when we are working with more experienced people or when the confidence about the domain is high we tend to go faster.
We try to make a refactor step after each test pass and try to enhance code in order to embrace business changes needs or reduce technical debt.
When our application is hard to change, we know we should refactor our code.
If we cannot do it immediately (e.g. due to a short deadline) we create a card with TD (Technical Debt) label and we do it as soon as possible.
There are different patterns that we employ everyday in order to improve the design of our production code, avoid duplication and express in a better way the intent of each component. Each person in our team has a different set of patterns in their toolbox but we try to use those that answer the four rules of simple design; anyhow most of the patterns we employ are taken from two books we warmly recommend: Refactoring by Martin Fowler and Refactoring to Patterns by Joshua Kerievsky.
TDD helps our teams in many ways. It allows us to see a new feature from the customer point of view.
In addition we can write more meaningful code for the business needs, which leads to have the code cleaner and more understandable for the entire team.
It permits to have a quick feedback and to not over-engineer the application, because we write only the code that is really needed.
Our customers feel a better quality in the software we deliver, because there are few bugs and we can fix them quickly.
The customer asks for new features with more confidence and trusts us. The software turns out to be more flexible and easier to extend.
There are many challenges that we try to face when we practice TDD in our team, and these challenges are not only related to technical aspects but also to different approaches that come from our different experiences.
In some situations we discuss a lot about the first test we should write when developing a new feature: shall we start with this case or another? In other cases we have to think carefully on our TDD approach; of course we love outside-in TDD but sometimes when we are confident we embrace inside-out as well.
Another challenge for an experienced member of the team is to pass down some values to younger people: first of all we teach that tests are code and therefore is important to give them all the respect they deserve and polish them using refactoring techniques, DSL etc etc. Moreover tests are made to be read by other people (not always technician) and we must try to make them as much expressive as we can.
The continuous integration environment heavily reflects the project itself. Its complexity and automation degree tell us what kind of environment to spin-up in order to be more effective and productive on a daily basis. We’ve used different tools in the past including Jenkins, GitlabCI, Travis, CodeShip, CircleCI, DroneCI for backend and frontend development. Bitrise and Buddybuild for mobile applications. At XPeppers, we prefer a streamlined continuous deployment or delivery approach to push artefacts towards production.
At XPeppers we provide either apprenticeship and internships programs. Both have a strong focus on learning the core principles, values and practices of our way of working. Apprentices are given the chance to deepen their understanding of eXtreme Programming, Clean Code and TDD by following an ad hoc tailored version of our study path with the support from the entire team.
On-boarding is another very important aspect that helps newcomers to become first-class XPeppers citizens. The on-boarding process is made up of activities other than simply studying, ranging from learning our culture, presenting their progress to others and joining all daily team activities.
Each team member at XPeppers has an ad hoc study path to improve both soft and technical skills continuously. We spend a certain amount of time each day to follow this path and to share know how with other team members by making presentations, pair programming sessions and other team activities that help us grow.
During our interviews at XPeppers we usually ask the candidate whether or not he/she has familiarity with practices such as TDD. If so, we ask further technical information about the subject and adopt TDD during subsequent exercises and pair programming sessions. If it turns out that the candidate has never done nor seen test driven development before, we try to understand how willing the candidate is to learn and improve his/her knowledge of our practices.