So I am building an application with Angular and have started to get into UI testing with DalekJS (http://dalekjs.com). As I have been writing these tests I have been thinking to myself, should I even bother with writing unit test that that are UI/UX components.
Now my angular services generally don't have anything to do with the DOM or directly rendering stuff on the page so those I unit test and it make sense however angular directives are components that render things directly to the page and writing unit tests seems like 1. It is not an effective way to test UI/UX components and 2. It would overlap with UI/UX Tests.
For point #1, unit test (at least ones I have seen) don't actually write anything to a browser and render it. For thing that require DOM, you generally mock the DOM in a variable and use that to test whatever you need to test. If you have an error with a test, you can't load it up in a browser and play around with it like you could with UI/UX tests (which in my experience runs against code that is the true application that renders and everything).
For point #2, one of my directives has a property called contentVisible. Now I can write a unit test that make sure that property is the correct value at certain points but that really don't not test what I truly want to test because even if contentVisible is set to false, the content still might be rendering to the screen which UI/UX test would pick up.
Is it still worth the effort to write unit test for UI/UX Components where UI tests would be able to pick up everything the unit test would plus also do a better job since it can test what is actually rendered?
Exception
The one exception case where I would need a unit test is for certain ajax requests. For example, making sure an ajax request is not made of that an ajax request that does not make and changes to the UI are things that can only be tested with unit tests.
Best Answer
My fuzzy answer is that sometimes having UI unit tests is a good idea, for some parts of the UI. In my experience:
Often the people responsible for functional and integration testing are different people than those responsible for unit testing (typically, QA vs. Dev). As such, each may spot different areas (and have different blind spots) as to what ought to be covered by tests.
Related to this, programmers should be responsible for testing their own code, and not defer some aspects simply because someone else is theoretically testing that code.
Unit tests are more targeted than full functional tests. While the latter might tell you that an expected button is not clickable, it won't instantly tell you that this is because it's
enabledproperty is false vs. it'sz-indexis wrong vs. its layout coordinates are outside the viewport, etc. Likewise, as you point out, the unit test can tell you that thevisibleproperty is set correctly, but does not necessarily tell you if the object is actually visible (though such tests are possible). In other words, even with trivial examples you can see that the two types of tests are not interchangeable.Belt and suspenders approaches are often fine [for software engineers].
Trying to test any aspect of code -- GUI, time-based, async -- will tend to improve one's thinking about that code and its design. The trade-off is that too many tests or testing the wrong level of abstraction can slow refactoring. But imho it's high-value to try to test any part and learn from experience what types of tests add the most value.
I've worked on a couple of large projects where having the programmers unit test a lot of parts of the UI saved a LOT of time and made the QA folks happier (and able to focus more on things programmers could not have spotted as easily). I should add, I do not like testing UI code because it's time-consuming and hard. In general writing tests is time-consuming but pays for itself rapidly, and good UI unit tests that add specificity to what functional tools can test are no exception.