Learned lessons on writing functional tests

No matter if your application is a legacy system, or a green field project, functional test are always useful. Nonetheless, if we are not careful writing these tests can be painful. So here are a few lessons that learn writing functional tests that hopefully will help you to write better functional tests.

Lesson 1: The code of your functional test is as valuable as the code of your actual application. 

A common error that make most developers when they are writing FT, is not being as careful as they may be when writing production code.  Is a natural mistake, I guess that the reason behind this is that we want to view our system working as soon as possible and automated test in general may be seen as a tedious step in the process see your system working.

But the truth is, the code of your FT is closely related to the functional requirements.  In fact, a FT will contain the code representation of your requirement (And you know how much they like to change). So, if your test is not readable, too complex, or have any of the commons code smells it will make your application harder to test.

Lesson 2: Use function composition whenever you can.

Systems in general (specially if they are successful), will grow in number of features. As your system grows in features a consistent look and feel is food for the business. New features in your system means also more functional test.

Function composition helps you to be in a better position to write new tests, if instead of copy and past code you create new functions you will encounter that  the time that you will spend on writing new functional tests will be lower.

Lesson 3: Make functions that encapsulates common controls.

Image that your are in charge of really big and complex system, and  of course written tons of functional tests, and so far your UI an fancy drop-down menu. Is quite common that fancy UI controls, requires a little more work to be used, but you are genius, you manage to select options in the drop-down menu in just one line of code. So why make a function that will only reuse one line of code, right?.

You know what happens with fancy UI controls? They are like fancy clothes, they change with the seasons. Is a matter of time for new fancier, prettier, cooler buttons appear.

Now you are in charge of change every fancy drop-down menu, for the fancier one.  But remember, your system is big and complex, there is so many drop-downs there that can’t be sure how mane of the are out there.  And probably your magic line of code won’t work anymore.

In this case, if you have a function that use that control, you can just change it to make it work with the new button. Then, change your production code in order to use the new drop-down menu. Finally, you can use your functional tests to check that your system is working properly.