Testing Driven Development Guide and recommendations
Our FrontEnd development is not the typical development, then, applying the Testing Driven Development methodology could differs from what many articles or sites recommend.
But the idea is the same, writing our test before implementing the feature, having a clear idea of what we need and design our feature taking the max number of scenarios to cover. The test will be failing, but the idea is to implement the feature and step by step, having each of our test passing.
Then, how we could take this approach and how this could help to improve our productivity?. Let’s jump on it!
Designing the test
The easiest way, given that we are designing and developing visual components, is to design a Sample/demo that covers the needed feature. You can follow these steps:
Research the feature/bug to have a clear path of the scenario(s). Design diagrams, guides, or anything you need to have the design clear.
We can design a sample inside our e2e sample, or a Sample (Winforms, PowerBuilder, Access, etc.) and migrate it to extract the screens and responses. See more of how to create a scenario here.
Then, after having the most complete coverage of the feature, we can start to write our tests scripts.
Our tests will be failing, sadly. But everything is ok! Because we will write our code to put all the test on a passing state.
Start the implementation. Here is where the magic starts!
To validate, go to substitute the dist inside the samples, and run the test.
If you are implementing the feature on a correct way, then the most expected moment will come. All your tests are passing!!!
Adjustments running the test
Maybe you will need to make some adjustments but, this methodology helps a lot on the design and development of the feature.
Can I write my unit test using this methodology?
Of course! But this needs more practice. The easiest way is to start by the visual test.
Last updated