Failing tests are an essential tool in software development. They are written to fail and their main purpose is to indicate that a feature or functionality in the software is not working as expected.
Failing tests are created before fixing a bug, and they help developers identify the root cause of the problem. Once the issue has been resolved, the test is expected to pass, indicating that the issue has been fixed successfully.
How Write a Failing Test
The process of writing a failing test is relatively simple. First, the developer writes a test that checks for the expected behavior of the code. Next, the test is run, and it is expected to fail since the code has not been written yet. Once the test has failed, the developer can then proceed to write the code that will make the test pass.
Real Case
For example, lets imagine we have a table of users in a web platform.
This table render three columns of information:
- name
- lastname
and, when clickin in a row must redirect to the user detail.
The prolem is when clickin in the row it is not redirecting. So, your failing test will:
- check the render of table
- can assert the column values
- can assert the row values
- and assert when clicking in the row it will redirect to the right route
Then, when running the test will fail and you will be able to fix it having a test already existing for the expect solution.
Conclusion
By finding a mistake/error/fail in the code and designing its failing test, it will be much faster to find the solution. Instead of trying to solve with n solutions and testing in the browser or wherever, you will have your test responsible for this, automating the process and saving time in the solution.
As a bonus that scenario will be covered for next steps and improvements in your code.
If you want to work in a startup in its early stages, This is your chance. Apply today!
Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.
Photo by Talha Hassan na Unsplash
Top comments (1)
Thank You for pointing this out.
I think writing a failing test and only later making it pass is not only TDD, but simply a sane practice. In my so far short career I've already seen many tests, which supposed to test something, but... When the piece of the code is obviously wrong those tests still pass.
Usually I noticed such things with mocking or where error is expected in one place, but is actually raised in another (unexpectedly).
So my personal workflow is to always check that test which I'm writing does fail when it has to fail and only later make it pass and refactor.