I think you should have two different tests.
You return a different status code based on what the value is in the database. You have defined two different behaviours: when the database is in one state, you return 200. When the database is in another state, you return 204.
But this is a unit test of your web-service - so the test should be decoupled from the database. You can and should use some form of test double (mock, stub, etc). This way the tests not only document the different possible responses, but give example scenarios of when to expect each response.
If you find you really want to connect to a database, your test specification should set the database state, i.e. delete the table(s), populate some test data for the test, then run the test. But this is not preferred - if your database is unavailable, you won't be able to test/build your API.
When you talk about changing it to always return 200, you're not talking about a refactoring that changes the implementation without changing the behaviour. That's an actual behaviour change, so it's natural that you would update the tests at this point.