Should I :
Thanks !
There is a widespread opinion that every test should test only one feature; the extreme version of this is that every test method may have only one assert. There is furthermore a common opinion that each feature should be tested only once; the extreme version of this is that every defect in your codebase should trip exactly one test.
I don't subscribe to the extreme versions of either principle, but the motivation behind the non-extreme versions is valid: code that serves two purposes is hard to understand, and test methods are code just as much as business methods; therefore testing only one thing at a time is generally a good idea. And the purpose of your tests is to warn you if regressions occur; preparing two warnings is simply a waste of effort that could be spent more productively.
But as always, there is a trade-off. If it takes more effort to duplicate the test scenario (either developer time or compile time) than you probably save in readability, extensibility etc. by making your code as clean as possible, then it can be the right choice to test several small things after building one expensive scenario - whether or not that is the case for you, we can't really tell.
DRY (don't repeat yourself) principle doesn't really apply to tests. This is because priorities change and your bottom line is that you want to ensure proper functioning of your program. In other words, don't be afraid to create a new test if you feel that the assertions for existing tests don't quite cover the new feature.
At the same time, I would be careful to ask myself if the existing test doesn't somehow also cover the new feature as well. To give you an example, suppose you currently have a test which performs a call to place an order.
The existing test verifies that the order is placed and that all the details are as specified. Now suppose for a moment that the new feature is to send an e-mail to the user which placed the order. To test this new feature, you must still place an order, and the existing test to verify placing an order still covers this new feature. Therefore you should add assertions to the existing test.
Otherwise, if you feel existing tests don't quite cover the new feature, you shouldn't feel afraid to create a new test with the express purpose of testing that new feature.
Should you write tests is what I heard you asking?
Well, why do we write tests? To reduce risk! If we want to reduce the risk of certain scenarios from happening it is best to write a test.
So if you think that there are not enough tests surrounding the new feature, please write tests.
But don't just write tests, and if they all pass then commit and push. You want to see the test fail, then add the code to make it pass, so you are EXACTLY sure you are fixing that one test. Also if you don't see the test fail, you could just be writing tests that don't actually test anything and might always pass.
