_ _
_ __ | |__ | | ___ __ _
| '_ \| '_ \| |/ _ \ / _` |
| |_) | | | | | (_) | (_| |
| .__/|_| |_|_|\___/ \__, |
|_| ...2017-11-15 |___/
If I was only writing here all the things I'm thinking to write, such a great
big place it would be, but I too often don't get it done, only thinks about it.
It's a wonderful book indeed! I'm having a great time reading it, and I feel
very much that I can't avoid taking on the tone of the book when writing.
There are many funny anecdotes and observations that I think many people can
still recognize in society today.
I read "The Soul of a New Machine" and "Dreaming in Code" recently, they are
also really great, and both definitely worth reading for anyone with either
an interest in the IT industry or computer history, and the stuff in
"Dreaming in Code" seems to be as true and relevant as ever.
My girlfriend and I went to London for a few days to look around, I've never
been there before, and was surprised to find that most people didn't speak
english very well, now, I don't mean that British is intelligible, rather
that there aren't many brits present there at all. I was surprised by that.
The Underground and bus transport systems worked very well, and it didn't take
many minutes of thinking to figure out how to get from one place to another,
even though it's a very big place. Found resturants advertizing as Authentic X,
substitute X for any word except British or English, so I didn't have a chance
to find out what kind of food were supposed to be typical, or, traditional at
least. I did have a reasonable enough pizza and some nice Indian food there, so
that was nice. Hotel breakfast was sub-par, but edible. Prices were about the
same as in Denmark, so, not suprisingly expensive, it's just that I also think
that Danish prices are generally unreasonable. The museums were awesome, and I
could definitely spend some more time in both Science, Natural History and the
British Museums (the British museum is basically the treasure chamber with all
the stuff the empire stole from the rest of the world, back when that was an
acceptable thing to do, and, so far, since many of those places are now
war zones or just generally undesirable, it seems that stealing all those
things were actually saving them, so it turned for the better I gues).
But for the museums, and the interestingness of the place, I never got the
idea that it might be a place where I'd want to live or work at any time in
my life, maybe for 2 weeks, but not more. Not that there's anything I found
negative about it, in my 4 days of visit, just, that there wasen't anything
I thought especially appealing about it either.
Headline stolen from "Dreaming in Code"
I think test-driven development holds some value, my theory being, that when
working on big systems, it will allow you to do much of the plumming of a new
part without the turnaround overhead of the big system (starting/stopping/con-
figuring) to see how each new change/progress works out. My idea, is instead,
that if you define a reasonable interface to your new part, you can trivially
plug it into your big system, but, you can also, trivially, plug it into a
unit-test, meaning that, you can write your unit tests first, and then put the
flesh on your new part. At least, that's my theory, and it's where I see the
very most value, there are other good things, and I don't disagree with their
importance, but for me, personally, what I think I can get more happiness out
of, is what I mentioned, being able to make changes, and see if they work, in
a second or less. Except, often, the second part is not trivial. It's easy
to plug something new into the big system, because there's a big system ready
to support the new part.. But, in a unit test, you start out, potentially, with
a lot less, and you end up havig to implement a lot of code to build for your
new part, an artificial environment, that behaves ENOUGH like the real big-
system. I was pretty sad to see that "nock" is the best "request" mock around,
it pollutes the global request definition because someone are not writing code
meant to be tested. Writing code for test-driven is not hard, and it does not
even have to be more inconvenient, example time, psudo code.
annoying-to-test.js:
const repository = require('the-repository.js');
module.exports = function SillyAccessor( resourceName ) {
return repository.get(resourceName).then( (item)=>{
return item.theImportantPart;
});
};
and entirely reasonable, like, connecting to a database server, using an URI
defined by an environment variable (because that's something that could happen)
Then you'll be in for a pretty bad time when trying to test that this function
actually returns "theImportantPart" of some "resource". The solution is simple,
make sure the things that "interact with the outside" are dynamically provided.
This is a silly function, but it could have been a class as well, same thing.
Here's a better way (tm)
easy-to-test.js:
module.exports = function SillyAccessor( repository, resourceName ) {
return repository.get(resourceName).then( (item)=>{
return item.theImportantPart;
});
};
method which ignores its argument (since we're doing nothing to that, it can't
break), and resolves a promise for an object with a key named theImportantPart.
Then, you can assert that, A: The get method is called, B: that the returned
promise resolves to whatever value you chose for theImportantPart.
Just something to keep in mind, as you go, it gets easier, because you will
have a larger selection of mocks, but often, if you want your tests to test not
only sunshine scenarios, but also determine and verify behaviour in the error
situations your code handles (it's one of my pet peeves, that code should
always handle errors, if only (and most times, only) to generate some kind of
usable error-message to display in the log (and maybe even the user, but I care
much more about the logs than the users in such cases, as the latter will most
often rephrase your carefully written error message as "it's not working and
then it says something on the screen that I don't know what is").
So, to test error scenarios, such as the database not connecting, or the
query failing, maybe in multiple peculiar ways, you want to be able to hack
your mocked resources to behave just so, for those instances, and that may
make them very specific to that particular unit test. But I've not proven
that, and I might try to do a more general solution for use in our big system.
I won't promise to do a greater effort with this blog, because it's a promise
that I can't keep, but I'll definitely continue thinking about such effort.
And to SDF too! ;)
- OUT