Thread by @dtanzer

In my #TDD trainings, I sometimes say that I do not test code that is "too simple to break"; Code where:

1. The chance of the code breaking is very low
2. *If* the code breaks, we would see immediately

What do I mean by that? A thread... 1/

I wrote the following Typescript code running in #electronjs:

const { dialog, } = remote
const filePath = dialog.showSaveDialogSync({...})
if(filePath) {
fs.writeFileSync(...)
}

The code is very hard to test, but I'm OK with that, b/c it fulfills the above criteria. 2/

Before I go into why the code is "too simple to break"... Why is it hard to test?

Well, "dialog" (and even "remote") is not available during unit testing. And even if it was, it would open a dialog that I'd have to remote-control. Not cool in a test. 3/

...and "fs.writeFileSync" has the side effect of writing the file.

If I splitted the original function, I could at least write an integration test for writing the file (call the new function, check if the file exists and has the correct content).

But would that be useful? 4/

My integration test would only test whether my wrapper function, that *only* calls writeFileSync, writes a file. So, it would indirectly *only* test writeFileSync.

Because I don't want to test framework code, this test has no value.

And even if it had, what about "dialog"? 5/

"dialog" & "remote" are my bigger problems, but can't i just mock / stub / fake them?

I don't want to do that because I usually only want to mock my own code. Mocking or stubbing code requires some deep knowledge about the mocked code - I only know my own code well enough. 6/

If I wanted to test the "dialog", it would have to be an integration test: A test that checks whether one small piece of my code integrates correctly with a framework, lib or 3rd-party system.

That's not easily doable here too. But the code is too simple to break anyway. Why? 7/

1. The chance of the code breaking is very low

The code does only two things: Open a save dialog, write the file. Everything else - preparing the data, handling the result and edge cases, must be done by the caller.

I'm hoping that this is write-only code: 8/

Code that I write once and never touch again.

And I can test all the interesting stuff by writing tests for the caller of this function (which I, of course, did *before* writing the code in the first tweet).

And the second criteria: 9/

2. *If* the code breaks, we would see immediately

Loading and saving files is some central part of the application. It's not some obscure feature that people will only use once a year or that only a very small percentage of our users will ever use. 10/

We probably cannot do even a single manual test without at least loading and probably also saving files. When we start the application at least once before deploying and try it a little bit, we will recognize errors in that code. 11/

And that's why not testing the code in a *unit test* or *integration test* is OK for me, for now.

This got quite long, it could have been a blog post. Maybe I'll write one for devteams.at/blog/ later. 12/12