How should test using tdd repeated behaviors - unit-testing

Question

I have the next code i made a test but now i have a dilema strictly speaking with tdd for add
"this.loadCounter('anotherReq', 'anotherError', differentCallback);"
i have to reply the tests only for test the behavior but i not sure if this is necessary.
class Statistic extends PureComponent<Props, State> {
state = {
};
componentDidMount() {
this.loadCounter('suggestedReqCount', 'hasSuggestedReqsErrors', getCountSuggestedReqs);
this.loadCounter('anotherReq', 'anotherError', differentCallback);
}
loadCounter = async (
stateCounterKey: string, stateCounterErrorKey: string, loaderFunction: Function) => {
try {
const count = await loaderFunction();
this.setState({
[stateCounterKey]: count,
});
} catch (ex) {
this.setState({
[stateCounterErrorKey]: true,
});
}
}
}
this are the test that i have
test('Should set state with suggested requirement count', async () => {
const wrapper = mount(
<Statistic
intl={{
formatMessage: jest.fn(),
}}
/>,
);
wrapper.update();
await getCountSuggestedReqs();
expect(wrapper.state().suggestedReqCount).toBe(5);
});
test('Should on fail load suggested reqs update state', async () => {
getCountSuggestedReqs.mockReturnValueOnce(Promise.reject('Error creado'));
const wrapper = mount(
<Statistic
intl={{
formatMessage: jest.fn(),
}}
/>,
);
wrapper.update();
await getCountSuggestedReqs();
expect(wrapper.state().hasSuggestedReqsErrors).toBe(true);
});

Answer 1

The first rule of TDD is that we cannot write any production code before having a failing test.
This alone implies that if you want to add production code, you have to write a test that will require it.
That said, there are cases where I won't write a unit test and let the larger tests grab that functionality, like in cases of simple delegation - the code isn't doing any logic, just passing the same arguments to another function, so there's nothing really to test, and the wiring will be tested from the outside.
In this case, however, it seems to me that you're invoking that function twice in order to get different information.
You could expand the existing test to include the new data, but I'm not a fan of that option. I would rather leave existing tests and add new tests for new functionality. Notice that "As the tests become more specific, the code becomes more generic", is true here too. Perhaps when the third call to loadCounter comes in, you'll need to refactor the code to be more generic, but at this point I would just add the second unit test.
All that said, you should definitely separate your logic code and your component code. There's no reason this unit test would be an Enzyme test. The code in componentDidMount could be easily refactored to a function that could be unit tested by just a plain ol' test.