TDD modifying my test to make my code pass

I'm learning Test Driven Development, i'm struggling a little bit, seems like my brain wants to build solution algorithm, and not the needed test to build my algorithm. I can barely formalize unit test, and i go back and forth to change my tests.
I come to a point where i make some adjustement in my code, and then i'm trying to modify my tests to make them pass! It should be the other way around.

i had initially this piece of code for test

    def test_is_zero_in_range(self):
        self.assertRaises(Exception, self._provServerPrepare.is_in_allow_range, 0)

so i write it up the code needed

    def is_in_allow_range(self, value: str) -> int:
        value = int(value)
        if value in MULTIPLY_PROV_RANGE:
            return value
        raise Exception('Value out of range')

as i'm working with flask, i changed my code to get a return with a message and an error code, rather than a raise exception

    def is_in_allow_range(self, value: str) -> int:
        value = int(value)
        if value in MULTIPLY_PROV_RANGE:
            return value
        return {"message": f"Value out of range"}, 400 

In this situation i have to change my tests to make it work, i'm not sure, but i feel like i'm messing with something, this doesn't seem right to me to do it that way.

Does anyone can help me on this, or have any resources for me to read/watch?

Thx

TDD is not the only tool in the kit.

> In this situation i have to change my tests to make it work, i'm not sure, but i feel like i'm messing with something, this doesn't seem right to me to do it that way.

You may be missing the technique of spiking.

In summary: when we aren't confident enough that we understand a problem well enough to produce a solution, we first perform some experiments to improve our understanding, and then from that new understanding we start the TDD process.

We're not necessarily trying to solve the whole problem, but instead to get enough of a sense for it that we are confident that an approach will be able to solve the whole problem.

Spiking includes one important constraint: if you want to reap the long term benefits of a test first approach, then you discard the work you do during the spike and "start from scratch" when the spike is over.

Spiking, as a practice, isn't a "TDD" practice as such. The practice (and the label for the practice) were inherited by the TDD community from the Extreme Programming community.

That said - when discover that a behavior described by your tests is wrong, or that the interface(s) between the test and the subject are not adequate, then yeah - bad luck, there are going to be changes to the tests.

Sometimes that is going to mean modifying the old tests; sometimes that will mean retiring the old tests and replacing them with something new.

You can sometimes use information hiding as a counter-measure against future changes - ie if you recognize early that a particular element in your design is unstable, then you might do a bit of extra work to reduce future damage if the unstable design does in fact rupture.

It happens all the time that after you write a test, you find that you need to change the return value from a function (or the exception that it raises). That's normal. The TDD way to address this is to change the test first to reflect the new correct return value. See that test fail, and then update your code to make it pass.

So, in your example, when you switched to flask, or when you realized that you needed to return a message and error code rather than raise an exception, you would first modify test_is_zero_in_range to require the message and error code, see it fail, and then update is_in_allow_range to make it pass. "Test first."

By the way, here are some alternative names for your test and your function, which you might like better:

test_zero_is_out_of_range  or  test_zero_should_be_out_of_range<br/>
is_in_allowed_range

This test name is more self-explanatory, since it states the intent of the test.

You're discovering your actual requirements and evolving your way there, which is one of the primary goals and benefits of TDD. There is nothing wrong with changing your mind.

If you have a dozen tests making a call, and then you need to change how that call works, you have two options:

• Use an IDE like PyCharm that supports the Change Signature refactoring.
• Extract a helper method on the test side that makes the call. Then you only have to change one place. Such helpers often move from test code to production code.

Another thing to be aware of with TDD: Don't start with an edge case. Instead, capture a stripped-down subset of what you want. At Industrial Logic, we call this Essence First. Throwing an exception is likely not the essence of the behavior you want to TDD, so don't start there. Instead, start with a minimal expression of the "happy path."