On 07/24/2018 12:41 PM, Arvin Schnell wrote:
I read the article  and some of the references about testing
and found it interesting and also disillusioning.
Good article, I fully agree with most of the points.
But it seems to be written in the scope of modern web development.
That's a much more friendly environment for integration testing and
On integration tests vs unit tests
The article is right here. Before joining the the YaST Team, I seldom
wrote unit tests for the components. Only for those which implemented
tricky logic (like the BootRequirementsChecker, to show a YaST-oriented
example). The biggest part of my tests were integration tests...
But that was in the web development world, in which writing integration
tests is a piece of cake. For example, in my last Rails (pre-YaST)
project I could tests the whole stack as easily as this:
To be more concrete, the following spec tests the rendered HTML, the
interactions between those parts) by just describing the user actions
and the application responses to them. Just describing the scenario like
"go here", "click on that button", "this should appear".
We are far from having something similar in YaST, that can be written
and maintained so easily and that can be run with a single command in
some seconds. For proper integration, we need to reproduce a whole Linux
system with some setup, to interact with the UI, to inspect the real
changes in the system... We have nothing of that, so we fallback to unit
testing, which admittedly implies a bigger level of mocking and provides
a way lower ROI.
On testing only the common cases but not the exotic ones
I partially disagree here. I really believe that thinking about the
boundary scenarios and the corner cases while writing tests for them
helps a lot to write better code from the very beginning and to reduce
After all, the errors in the "happy path" are obvious enough to be found
easily0, even manually. One of the things I like more about testing is
the exercise of challenging your code with different situations.
Of course, that implies an approach to testing based on scenarios and
BDD, not just repeating the implementation with the RSpec syntax.
Because when we write tests that are suspiciously similar to the
implementation we are indeed just pleasing the code coverage stat with
no real gain.
Unit tests and the ossification of the internal structure
I agree with the main point here. But again, that depends on the context
for which the article is written. If you are just writing a web
application to be used via browser, then you don't want the API of your
components to get "ossified". You only care about the user-visible behavior.
But an important part of the work in YaST is about writing APIs to be
consumed in several parts of the project. Usually in other YaST modules
living in another repository. And you really want those APIs to be ossified.
The smaller internal classes and methods should be tested indirectly,
using the more external API instead of calling every single method
explicitly in the unit tests, but they should still be unit-tested.
Ancor González Sosa
YaST Team at SUSE Linux GmbH
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org