Is testing UI components considered to be unit testing? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

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.

Answer 1

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.

Answer 2

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.