Behaviour Driven Development: Experimenting

The main purpose of the Unity Integration Tests is to help you to set your objects in the scene and develop your scripts also by experimenting the results of your work. It is right, all the developers have to learn new concepts and technologies all the time, and experimenting with the process “Try and Error” is a natural way to learn. However, this type of development is not related to the objectives of the Behaviour Driven Development. Experimenting new technologies is a fundamental part of your job, but you cannot develop in BDD using this approach. It does not mean that you have to give up with your experiments. You could start you developing session with BDD, but sometimes, during your coding, you could find some technology you do not know perfectly. If it happens, you could start to experimenting during your BDD process. In this case, we recommend paying close attention. During your experiments, you are going to write much code that is going to be useless (dead code) or not optimised, often very messy. During your experiments you could lose the focus to make a clean design, that is one of the main objectives of the BDD approach.

At the end of your coding session, when your code works properly, you could take three different approaches:

  • Refactoring: You should have a refactoring session every time, even if you are not experimenting. It is an important part of the process. It allows you to clean your code and organise it in a better way. However, sometimes you could lose the design scope of BDD. If you think your code does not match anymore with the natural behaviour of the users of your software, you could consider the second approach.

  • Develop your code again using BDD: Sometimes your code is so messy that you could think it is irrecoverable: you could try to write your code again using the new skills you just acquired about the new technology. This approach allows you to get your thoughts together and write better code.

  • Both the approaches: the better way could be to take both the approaches. It means to make some refactoring of the core classes that use the technology you are learning and using BDD to design a clearer pool of classes that use the refactored ones.

 

You could feel to have to do extra work: Why do I have to write again a code that took me a week to work fine?

The answer is simple and significant. You have an objective that is not only to code a working software: writing code that is clean, readable, maintainable, reusable.

 

Back to: Behaviour Driven Development: how to organise the BDD Components Read next: BDD Framework: how to use it and avoid mistakes

 

© 2017 Hud Dimension. All Rights Reserved.

Search