# Test-oriented development, Julia, and me

**URL:** <https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245>\
**Category:** General Usage\
**Tags:** testing\
**Created:** [April 9, 2018, 2:27pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245 "2018-04-09T14:27:53Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![non-Jedi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/non-jedi/32/3645_2.png) [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)\
**Post date:** [April 9, 2018, 2:27pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/1 "2018-04-09T14:27:53Z")

</div>

Like many users of Julia, I’m an engineer who mostly uses it to write one-off  
scripts and do ad-hoc calculations. But I’ve also started to try to wrap up  
some of my more commonly-used functionality into packages for re-use and finding  
out: **I have no idea how to write proper tests**.

The two big questions I can’t seem to figure out are:

1. How big of pieces of functionality count as a unit and should have tests  
written for them?
2. How do you structure a package so that it’s easily testable? I find this  
especially difficult since some of the packages I’m writing wrap  
functionality from other sources, and I don’t really want to test that the  
external dependency is working as expected nor require installation of the  
external dependency for execution of tests.

Any advice? Or maybe a good tutorial on testing that’s language-agnostic enough  
to be applicable to Julia?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 9, 2018, 2:32pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/2 "2018-04-09T14:32:34Z")

</div>

You learn these by doing, it is difficult to give general advice. There are books on the topic, but the best teacher is experience, along the lines of “if I tested that I would have saved two days of debugging”. That said,

1. you can (and should) test small pieces when it makes sense,

2. break up things into small functions, which is good style anyway, and the compiler likes it too, so it is an overall win.

3. you don’t need to test functions from other packages. If you find something lacking coverage, just make a PR for that package.

---

<div class="post-metadata">

**Author:** ![non-Jedi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/non-jedi/32/3645_2.png) [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)\
**Post date:** [April 9, 2018, 2:36pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/3 "2018-04-09T14:36:07Z")

</div>

To be more clear, I’m specifically talking about wrapping non-Julia stuff in  
point 2. For example, this weekend I hacked together a lightweight wrapper for  
[taskwarrior](http://taskwarrior.org). Most of the top-level functions  
eventually call a function that calls taskwarrior. How do I structure the  
library so that I can test that kind of stuff without actually calling the  
`task` binary?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 9, 2018, 2:40pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/4 "2018-04-09T14:40:20Z")

</div>

Hard to say without seeing your code. If, for example, you have functions that emit/parse data for/from an external library, you can test these.

Note, however, that your will not be testing important functionality if you don’t test the actual interface to this library. Setting up a testing framework for this is usually more involved, eg your test script would need to download and install it.

---

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [April 9, 2018, 3:27pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/5 "2018-04-09T15:27:37Z")

</div>

> [@non-Jedi](#):
>
> nor require installation of the external dependency for execution of tests.

I don’t think you can really test a wrapper, without having the external dependency available for the tests.  
If there is some stuff that you want to use in the tests, which _isn’t_ required for people just using the package, then you can have a separate `REQUIRE` file in your `test` subdirectory.

---

<div class="post-metadata">

**Author:** ![jonathanBieler](https://avatars.discourse-cdn.com/v4/letter/j/82dd89/32.png) [@jonathanBieler](https://discourse.julialang.org/u/jonathanBieler)\
**Post date:** [April 9, 2018, 4:27pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/6 "2018-04-09T16:27:00Z")

</div>

For 2. I think you want to test that your wrapper interact correctly with the library, say if you have a `launch` function that starts taskwarrior, you want to check that it actually starts it. When it comes to dependencies, most packages download/install/build them for you when it’s possible, and that’s part of the tests (it’s also very tedious to test it manually on different machines, so having it in the tests saves you some pain). Since taskwarrior seems to be available on most package manager that shouldn’t be too hard to do with BinDeps.

---

<div class="post-metadata">

**Author:** ![non-Jedi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/non-jedi/32/3645_2.png) [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)\
**Post date:** [April 9, 2018, 7:07pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/7 "2018-04-09T19:07:03Z")

</div>

Thanks everyone. This was all helpful as basic as I’m sure it seemed to y’all. I  
think part of the problem I was having was that I was laboring under the  
impression that the units in “unit testing” were separate pieces of code that  
should only be tested independently from each other. There was a comment made on  
gitter today saying that when testing, you should think of units building up  
into bigger units building up into bigger units, and tests should be done at  
each level of agglomeration. Thinking about it that way, the proper approach  
seems much more clear.

Anyway, thanks again for entertaining the super-basic questions of an engineer  
who doesn’t _really_ know what he’s doing in software. 😉

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [April 9, 2018, 7:10pm UTC](https://discourse.julialang.org/t/test-oriented-development-julia-and-me/10245/8 "2018-04-09T19:10:07Z")

</div>

He probably needs something like: [unittest.mock — mock object library — Python 3.10.6 documentation](https://docs.python.org/3/library/unittest.mock.html)