I have 2 cases of similar context:

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 1

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 1

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-tested to do field that it calls any onSubmit handler upon submitting, wouldn't this to do app test case indirectly repeating to 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)

• Unit test to do app to assert...
  • that to do app's addTodo() method adds a todo item properly
  • that to do app renders to do field sub-component
  • and that to do app passes addTodo() to as onSubmit handler to to do field
• 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

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.