My UI components are tightly coupled with my UI framework (i.e. Vue + Vuetify). The framework provides some testing utilities that allow you to fake the rendering of these components without the need for a browser. Then, I use a testing framework (i.e. Jest) to take a snapshot and assert specific values and behaviors of my components. However, I am not mocking any of the UI framework dependencies, and if I do so, I would not be able to render my components and test them. Is this kind of testing considered to be unit testing of UI components without mocking the UI framework? What is it called then? Is my approach to unit testing here correct? Should I mock the framework and how?

Thank you.

closed as too broad by gnat, Jörg W Mittag, BobDalgleish, Robert Harvey Apr 30 at 17:52

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Not sure of the down votes for an innocent and basic question in software engineering?! Am I missing a rule in here? – geeko Apr 28 at 3:20
  • There is a lot of debate about the scope and meaning of the term "unit test". Your question falls into the middle of the debate and there is no good, independently verifiable answer to your question. – BobDalgleish Apr 29 at 21:30
  • I wouldn't know that unit testing is still a developing terminology in the field without actually asking. Trust me, if I knew this, I wouldn't ask in the first place. – geeko Apr 30 at 2:15

Frameworks (not just UI frameworks) are usually seen as a platform for software, just like the programming language itself or a basic data types like a string type or container types. It is seldom sensible to "inject" such framework dependencies, since the purpose of dependency injection is to make unit testing simpler, not harder. Furthermore, lots of platforms are considered to be reliable enough that decoupling one's code from the platform itself does not bring any benefit for testing.

So yes, unit testing of UI components without mocking the UI framework is usually still called unit testing.

I write "usually", since you will always find exceptions from this rule. For example, if your framework contains components which make the tests slower or more complicated, you may find it helpful to mock those parts out, even if you don't do this for other parts of the framework.

So instead of investing too much time in thinking about if a test is literally a unit test or not, better use that time and think about if the test tests what it should, if it is readable and maintainable, and if it runs fast enough.

The Way of Testivus has some useful recommendations here, especially Don’t get stuck on unit testing dogma and The test is more important than the unit.


The definitions of "unit" has changed over time. The idea (and I mean the IEEE definition of the idea that has since changed) used to be more based in OOP and the idea was that "units" were larger pieces of an app that interacted with other larger pieces of an app. The idea being that it was at those points that the highest risks were incurred by changes so those spots were most worth keeping an eye on as apps changed over time. It's almost as if they thought it might be a waste of time to let the testing of every corner of an app drive their architecture away from legibility, ease-of-modification, and reuse, to the altar of everything being easily tested.

Since then, reason has prevailed and it has been determined that we should test every smallest piece of our apps (the modern "unit") possible to make sure nobody has made a misstep.

But what were those devs from the '80sish-90sish thinking?

Perhaps they were under some delusion that you couldn't possibly check every single assumption with another assumption, but that you could at least check spots where Object A was supposed to shake hands with Object B with a variety of different hands/greetings/circumstances/etc and see if there was an unexpected miss due to some change made that didn't account for some interaction required by some other aspect of the app that the change-making dev was less familiar with. Mad they were, those people who originally coined the term "unit testing" because clearly, we must not only test our own code but also the code in frameworks that are used by tens of thousands daily and even the browser APIs which are tested by billions daily by accident.

IMO, you should map every single possible entry/exit point of whatever framework you are using so that you can mock every last piece of it and tell whoever is pressuring you to get 100% code coverage that you are indeed doing so and even though all of your estimates just went up by 10 orders of magnitude, that holy !@#$ are you guys going to be covered in case there is the slightest misstep made by browser developers, framework developers, or anybody on your team and they can rest assured that no mistakes will have been made on their watch, by the developers.

Not the answer you're looking for? Browse other questions tagged or ask your own question.