Background: I am new to testing in general, and have been studying it in context of JavaScript, specifically React.js, front-end development (actually new to this as well). For the question, I have these 2 similar cases:
Case 1: My code and a library
I'm using UI library and aside from its decent design, I want to leverage its form validation utilities. I want to test this validation, but not sure how to do it.
Option 1: Just test for the behaviors I expect
It would be testing if my field (which is a sub-module of the library itself) receives the library-specific classes for fields with errors as expected, and if these errors prevent from calling the submit handler I passed to the form (also sub-module of the library).
Problem A with Option 1
I am very likely to be duplicating tests that are already covered by the library itself. (e.g. I am testing if the field receives the error classes when the input is invalid when the library itself has tested if it does so, given the right configuration.)
Problem B with Option 1
It slightly couples the test code to the library, i.e. I have to use library-specific classes and markup to evaluate my code.
Okay, this is actually a side-question, is this a bad thing for a test? Is this making the test brittle, or is what they call 'contract' that is actually necessary for unit tests?
Option 2: Test which sub-module is used and what configuration is passed
Problem A with Option 2
This is much more brittle, I think, It's almost like repeating the implementation (i.e. repeating the type sub-module used, and the configuration passed to it.)
Problem B with Option 2
Same as Option 1's Problem A -- coupling test to the library's API, specifically its configuration API. (Again, not sure if this is just test being brittle, or contract being written)
Case 2: My code and its sub-component
I have my good 'ol to do app
. Its to do list
component has addTodo()
method and it passes to its sub-component to do field
. I want to test its feature to add todo item, but not sure on how to do this either.
Option 1: Again, just test for the behaviors I expect
Test `to do app` that if input and submit with sub-component `to do field`, another `to do item` is added. (This is implemented by passing `addTodo()` method from `to do app` to `to do field` as onSubmit handler)
Problem A with Option 1
If I'll do this, is there still a point in unit testing the
to do field
alone? If I already unit-testedto do field
that it calls any onSubmit handler upon submitting, wouldn't thisto do app
test case indirectly repeatingto do field
's test case??
Option 2: Test if correct sub-component is used and what configuration is passed (Similar to Case 1's option 2)
Its specs would look like this:
- Unit test
to do app
to assert...- that
to do app
'saddTodo()
method adds a todo item properly - that
to do app
rendersto do field
sub-component - and that
to do app
passesaddTodo()
to as onSubmit handler toto do field
- that
- then also unit test
to do field
to assert that...- that
to do field
calls the onSubmit, which is received from parent component, during submit
- that
- Unit test
The Question
Which of these options are better, especially if I favor BDD over TDD? Also, please correct me if you noticed I misunderstood anything. Thank you.