Final thoughts

For my final research journal entry I would like to wrap up the learning I have inadvertently done whilst learning about automated testing tools in preparation for my PRJ701 course. This learning is about the Test-Driven Development (TDD) framework which comes under the Extreme Programming (XP) Agile framework.

As I have discussed in multiple previous blog posts (‘How can Agile methods and DevOps improve IT project success rates?’, ‘What is DevOps? and how does it relate to Agile methods?’, ‘What is Agile methods, Scrum, and Kanban?’ blogs) Agile methods is a mindset (you could also refer to it as a way of thinking) based on four values and 12 principles outlined in the Agile Manifesto which was written in 2001 (see here for the principles and values

The methodologies that follow the Agile mindset are called frameworks and XP is a framework.

XP is very much a technology focused framework due to its use of Peer programming, Test-Driven Development, Refactoring and Continuous Integration; all of these practices are software specific, as opposed to Scrum which can be applied to non-IT projects.

Test Driven Development is where the developer writes unit tests (these test a small chunk of the code for example a single function or small piece of functionality) before actually writing the code that will be tested. When I say the developer writes the test, this will be in a testing environment such as Selenium and these are automated tests plans. At this stage the test will fail because there is no code written yet for it to test.

The benefits of writing the test before starting the development phase are that it forms part of an executable documentation i.e. it is documenting the user requirements  because each unit test is based on the user requirements being broken down to their smallest component. So by writing the unit tests you are also documenting the user requirements at the same time.

Secondly you are ensuring that all software will be tested because the test is written before the feature itself is written meaning the developer can test as they go, they do not have to find time to write a test after the feature has been written.

And thirdly you ensure that the user requirements documented in the automated unit tests are met and no extra unnecessary code of features are added. This benefit of the TDD is basically keeping development time and costs down by focusing the development team.

Another thing to keep in mind with TDD is that refactoring takes place after the developer has written the code, and the unit test successfully passes.

Whereas BDD (as I discussed in my blog ‘What is the Behat Framework and the Repository design pattern?’) concentrates more heavily on the client rather than the development team and their agility.

BDD does this by attempting to make the on-going intra-team and inter-team communication (i.e. inside the development team and between the development team and the stakeholder specifically the client) easier through the development of a common glossary of terms known as the Ubiquitous Language.

These terms are already familiar to the client (because they are based on the problem domain that the system is being built for) but it is useful for the development team to use them so when developers with different levels of knowledge and experience in the problem domain collaborate or communicate they have a common set of terminology which they all understand. I would say that this is especially useful in a remote team, because I know having terms documented in the Koha Wiki (I work in the Koha team at Catalyst in Wellington) is incredibly helpful with my remote work because I can understand what people say without having to send a clarifying message or email which takes longer to get a reply from than if your are doing face-to-face communication.

In BDD the developer writes BDD behavior tests before the coding begins and these tests record a larger set of functionality than the unit tests written in TDD and the trouble with these tests is they are like a black box; you put in a specific input and expect a particular output and if you don’t get that particular output value then the test fails but you don’t know which function failed.

Whereas the TDD unit tests are more useful in troubleshooting because they are more fine grained and so it is easier to identify what is causing the error to be thrown. That being said unit tests are not the only automated tests written in TDD also Integration Tests are written to test if large parts of the system integrated together work as intended. The combination of Unit and Integration Tests in TDD is a great advantage from a troubleshooting point of view because you have both the fine grained and big picture tests provided.

So in conclusion in my opinion TDD is more development focused by making the troubleshooting failed tests easier through the combination of unit and integrated tests whilst BDD is more client focused and the troubleshooting following a failed behavior test is slightly harder to perform.

Thanks very much for reading, and thanks to Clare (hope you feel better soon) and Belma for teaching RES701 I have really enjoyed the thought-provoking topics and I am really glad I choose to take this paper  🙂



Farcic, V. (2013, December 20). Test Driven Development (TDD): Example Walkthrough | Technology Conversations. Retrieved June 8, 2017, from

Kumar, M. (2012, November 5). What is TDD, BDD & ATDD ? – Assert Selenium. Retrieved June 8, 2017, from

Test-driven development – Wikipedia. (2017, April 21). Retrieved May 29, 2017, from




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s