While Thomas Ferro makes some valid points about the function of these components, I have a different perspective on the preferred method to use. In my view, it is always best to utilize mount over shallowMount.
To support my argument, I would like to reference an article written by Martin Fowler:
There are two distinct approaches to TDD: mockist and classical TDD. When everything is mocked in your test, there is a high level of dependency knowledge within the test itself. This means that when a method from a child component or dependency is called, the test is aware of it.
In classical TDD, the recommendation is to only mock the Boundary layer (which includes web calls, filesystem calls, database calls, and view calls), and nothing else. Therefore, the term "unit" or System Under Test does not necessarily refer to a single object but rather a group of objects.
This distinction leads to the advantage of classical TDD, where changes in method names do not affect the test outcomes. In contrast, mockist style tests may fail if method names are altered. The essence of classical TDD lies in focusing solely on input-output verification while disregarding intermediate details.
By treating the test as if the dependency does not exist (except in the constructor), classical TDD allows for seamless refactoring and code transformation without impacting test results. This approach ensures that tests continue to pass even if methods in dependencies are modified.
Exceptions to this rule include web calls, repository calls (such as database or file system interactions), and view calls. Aside from these scenarios, classical TDD emphasizes the validation of inputs, outputs, and states rather than dependencies.
Therefore, transitioning a child component to the main component or another child component should not disrupt test outcomes when following classical TDD principles. Ultimately, classical TDD enables developers to refactor with confidence and maintain test integrity through its focus on input-output verification.