You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
156 lines
7.1 KiB
156 lines
7.1 KiB
11 months ago
|
<!DOCTYPE html>
|
||
|
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
||
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
||
|
|
|
||
|
|
<!-- Enable responsiveness on mobile devices-->
|
||
|
|
<!-- viewport-fit=cover is to support iPhone X rounded corners and notch in landscape-->
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1, viewport-fit=cover">
|
||
|
|
|
||
|
|
<title>Julio Biason .Me 4.3</title>
|
||
|
|
|
||
|
|
<!-- CSS -->
|
||
|
|
<link rel="stylesheet" href="https://blog.juliobiason.me/print.css" media="print">
|
||
|
|
<link rel="stylesheet" href="https://blog.juliobiason.me/poole.css">
|
||
|
|
<link rel="stylesheet" href="https://blog.juliobiason.me/hyde.css">
|
||
|
|
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface">
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body class=" ">
|
||
|
|
|
||
|
|
<div class="sidebar">
|
||
|
|
<div class="container sidebar-sticky">
|
||
|
|
<div class="sidebar-about">
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me"><h1>Julio Biason .Me 4.3</h1></a>
|
||
|
|
|
||
|
|
<p class="lead">Old school dev living in a 2.0 dev world</p>
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<ul class="sidebar-nav">
|
||
|
|
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/">English</a></li>
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/pt">Português</a></li>
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/tags">Tags (EN)</a></li>
|
||
|
|
|
||
|
|
<li class="sidebar-nav-item"><a href="/pt/tags">Tags (PT)</a></li>
|
||
|
|
|
||
|
|
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<div class="content container">
|
||
|
|
|
||
|
|
<div class="post">
|
||
|
|
<h1 class="post-title">Things I Learnt The Hard Way - Unit Tests Are Good, Integration Tests Are Gooder</h1>
|
||
|
|
<span class="post-date">
|
||
|
|
2019-06-19
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/book/">#book</a>
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/things-i-learnt/">#things i learnt</a>
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/unit-tests/">#unit tests</a>
|
||
|
|
|
||
|
|
<a href="https://blog.juliobiason.me/tags/integration-tests/">#integration tests</a>
|
||
|
|
|
||
|
|
</span>
|
||
|
|
<p>The view of the whole is greater than the sum of its parts. And that includes
|
||
|
|
tests for the whole compared to tests of single things.</p>
|
||
|
|
<span id="continue-reading"></span>
|
||
|
|
<p>First, I just don't want to into a discussion about what's the "unit in a unit
|
||
|
|
test"<sup class="footnote-reference"><a href="#1">1</a></sup>, so let's take the point that a unit test is a test that tests a
|
||
|
|
class/function, not the whole system from end to end, which would require data
|
||
|
|
flowing through several classes/functions.</p>
|
||
|
|
<p>There are several libraries/frameworks that actually split this in a way that
|
||
|
|
you can't test the whole.
|
||
|
|
<a href="https://spring.io/">Spring</a>+<a href="https://site.mockito.org/">Mockito</a> is one of
|
||
|
|
those combinations -- and one that I worked with. Due the bean container of
|
||
|
|
Java, the extensive use of Beans by Spring and the way Mockito interacts with
|
||
|
|
the container, it's pretty easy to write tests that involve only one class:
|
||
|
|
You can ask Mockito to mock every dependency injection (so it injects mocked
|
||
|
|
beans instead of the real ones) in one class and mock every injected class,
|
||
|
|
simply using annotations.</p>
|
||
|
|
<p>And this is cool and all and makes tests simple and fast. But the fact that we
|
||
|
|
are making sure each class does what it should do, it doesn't give a proper
|
||
|
|
view of the whole; you can't see if that collection of perfectly tested
|
||
|
|
classes actually solve the problem the system is responsible for solving.</p>
|
||
|
|
<p>Once, in C++, I wrote an alarm system
|
||
|
|
<a href="https://en.wikipedia.org/wiki/Daemon_(computing)">daemon</a> for switches. There
|
||
|
|
were three different levels of things the alarm system should do, depending on
|
||
|
|
the incoming message from a service: It could only log the message of the
|
||
|
|
incoming error, it could log the error and send a SNMP message, or it could
|
||
|
|
log the error, send a SNMP message and turn a LED in the front panel on.
|
||
|
|
Because each piece had a well defined functionality, we broke the system in
|
||
|
|
three different parts: One for the log, one for the SNMP and one for the LED.
|
||
|
|
All tested, all pretty. But I still had a nagging feeling that something was
|
||
|
|
missing. That's when I wrote a test that would bring the daemon up, send some
|
||
|
|
alarms and see the results.</p>
|
||
|
|
<p>And, although each module was well tested, we still got one things we were
|
||
|
|
doing it wrong. If we never wrote an integration test, we would never catch
|
||
|
|
those.</p>
|
||
|
|
<p>Not only that, but because we wrote a test that interacted with the daemon, we
|
||
|
|
could get a better picture of its functionality and the test actually <em>made
|
||
|
|
sense</em> -- as in, if you read the unit tests, they seemed disconnected from
|
||
|
|
what the daemon was expected to do, but the integration tests actually read
|
||
|
|
like "Here, let me show that we actually did what you asked". And yes, this
|
||
|
|
was akin to <a href="/books/things-i-learnt/gherkin">Gherkin</a> tests, although I didn't
|
||
|
|
know Gherkin at the time -- and, better yet, we had tests that proved that we
|
||
|
|
were following the <a href="/books/things-i-learnt/spec-first">spec</a>.</p>
|
||
|
|
<p>Personally, I think over time integration tests become more important than
|
||
|
|
unit tests. The reason is that I personally have the feeling<sup class="footnote-reference"><a href="#2">2</a></sup> that unit
|
||
|
|
tests check if the classes/functions have <em>adherence</em> to the underlying
|
||
|
|
<em>design</em> -- Does your view can actually work without the controller? Is the
|
||
|
|
controller using something from the model or using things that should be in
|
||
|
|
the view? -- but adherence to the design gets better over time -- developers
|
||
|
|
start using the layout from previous examples, so they capture the design by
|
||
|
|
osmosis, while the big picture starts to get more and more complex, with lots
|
||
|
|
of moving parts.</p>
|
||
|
|
<div class="footnote-definition" id="1"><sup class="footnote-definition-label">1</sup>
|
||
|
|
<p>There is no "unit" in "unit tests". "Unit test" means the test <em>is</em> a
|
||
|
|
unit, indivisible and dependent only on itself.</p>
|
||
|
|
</div>
|
||
|
|
<div class="footnote-definition" id="2"><sup class="footnote-definition-label">2</sup>
|
||
|
|
<p>Again, it's pure feeling from my experience. I have no data to back that
|
||
|
|
affirmation up, so take it with a grain of salt.</p>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
|
||
|
|
<div style="float:left">
|
||
|
|
<< <a href="/books/things-i-learnt/users">Think About The Users</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<div style="float:right">
|
||
|
|
<a href="/books/things-i-learnt/tests-dead-code">Testing Every Function Creates Dead Code</a> >>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|