Indeed, this is a common concern when practicing TDD, regardless of whether you test a UI component or a service. I mean, when TTD-ing a new service method you first wanna make sure the method is defined and can be accessed, while following tests use it to make sure it works as expected, so dose it make the initial test redundant? I does not IMO. Same when you test different usages of the method - some tests are bound to overlap.
The thing about TTD is that you build your service method or component one baby-step at a time, so first you wanna create the button and then you wanna attach some functionality to it. From my experience it has a lot to do with self-discipline and not jumping ahead of oneself. It is amazing how much frustration you save for yourself practicing it this way.
It can happen that multiple tests overlap and test the same code several times and that's ok. I think that it also makes it much more readable as a "spec" for someone who wants to create a component just by satisfying the tests:
Confirmation component should render
Confirmation component should have a title saying "Confirmation"
Confirmation component should have a dynamic confirmation question
Confirmation component should have an "OK" button
Confirmation component should have an "Cancel" button
Confirmation component should be able to receive a handler for the "OK" button and execute it upon click
Confirmation component should be able to receive a handler for the "Cancel" button and execute it upon click
I'd argue that for service it's the same case. So when testing a service, do you first check if the method exist?
While I understand how TDD by small steps helps focusing while building the component, I also appreciate the refactor part of the TDD cycle, and use it to refactor the code as well as my tests, and for me, clicking a button, requires it to be in the DOM so the test that checks this is redundant and I will therefore remove it in the refactor stage
At the end of the day, we do what helps us the most.
I like to think of the test I'm writing as a solid ground I blindly rely on and therefor I usually don't refactor them. I refactor the code it tests, knowing they protect me from my mistakes.
In my eyes tests should as simple as possible, with no implicit side effects. I see the the title of a failed test and I know right away what happened, no assuming or guessing, and yes - I write a test to make sure a service method is there, for I am willing to pay that price ;)
Well TDD brings refactoring freesom, so you're missing out ;)
Regarding blindly relying on them, you can still do that, since the tests are also tested - by the code
In general you’re right, but if you won’t remove the first test, then both will fail. For some people it will be enough to understand a reason just by looking to the names of failed tests.
In your case developer will have to look in the message of failed test.
That’s how I understand the idea of writing tests with such granularity
How many tests do you expect to fail if you make the button not available?
I think 2 failing tests are more confusing than one, even if I have to read the message (the title still helps me understand what failed - clicking the button)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great TDD walk through 👏
Once you added the tests for the buttons functionally, aren't the ones that test their existance redundant?
Cheers :)
Indeed, this is a common concern when practicing TDD, regardless of whether you test a UI component or a service. I mean, when TTD-ing a new service method you first wanna make sure the method is defined and can be accessed, while following tests use it to make sure it works as expected, so dose it make the initial test redundant? I does not IMO. Same when you test different usages of the method - some tests are bound to overlap.
The thing about TTD is that you build your service method or component one baby-step at a time, so first you wanna create the button and then you wanna attach some functionality to it. From my experience it has a lot to do with self-discipline and not jumping ahead of oneself. It is amazing how much frustration you save for yourself practicing it this way.
It can happen that multiple tests overlap and test the same code several times and that's ok. I think that it also makes it much more readable as a "spec" for someone who wants to create a component just by satisfying the tests:
I'd argue that for service it's the same case. So when testing a service, do you first check if the method exist?
While I understand how TDD by small steps helps focusing while building the component, I also appreciate the refactor part of the TDD cycle, and use it to refactor the code as well as my tests, and for me, clicking a button, requires it to be in the DOM so the test that checks this is redundant and I will therefore remove it in the refactor stage
At the end of the day, we do what helps us the most.
I like to think of the test I'm writing as a solid ground I blindly rely on and therefor I usually don't refactor them. I refactor the code it tests, knowing they protect me from my mistakes.
In my eyes tests should as simple as possible, with no implicit side effects. I see the the title of a failed test and I know right away what happened, no assuming or guessing, and yes - I write a test to make sure a service method is there, for I am willing to pay that price ;)
Well TDD brings refactoring freesom, so you're missing out ;)
Regarding blindly relying on them, you can still do that, since the tests are also tested - by the code
I guess, it can help you in the situation when you created a button, but forgot to attach an event listener.
Consider some big refactoring of the component – it probably can happen
In such case the functionality test would fail thanks to
getByRoleIn general you’re right, but if you won’t remove the first test, then both will fail. For some people it will be enough to understand a reason just by looking to the names of failed tests.
In your case developer will have to look in the message of failed test.
That’s how I understand the idea of writing tests with such granularity
How many tests do you expect to fail if you make the button not available?
I think 2 failing tests are more confusing than one, even if I have to read the message (the title still helps me understand what failed - clicking the button)