I have a project that I am building that I have to change a method to behave slightly different. I have several unit tests already built against that method, but I will need to add more to cover the new behavior I am going to add to it. Is it good form to change/add those tests first before making the code change, or do you change your code, fix the broken tests and add the new tests to cover the new behavior?
It often makes sense to write the test first and then write as much code as needed to allow the test to pass. Doing this moves towards a practice known as Test-Driven Development (TDD). Bluefruit uses a lot of TDD because it helps us to build the right product without waste and redundancies.
The idea is to develop a unit test by following these 3 simple steps: Arrange – setup the testing objects and prepare the prerequisites for your test. Act – perform the actual work of the test. Assert – verify the result.
Every time you need to. Tests should be changed if they become inaccurate, or don't follow specs anymore. Tests should be removed if they have become irrelevant.
If you're to follow TDD practices, you should update your tests first. You'll have broken test cases that should hopefully get fixed when you fix your code.
It is better to update the tests first and let them fail and then go back and update the code until the test passes. A.K.A Test driven development or Test first development.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With