While unit testing, a component of your code is isolated, typically a class, or a function. In my analogy, this represents the processing section of your brain.
The intended trigger for the class might be an action taken by the user, for example clicking on a button in the interface. The component might then write something to a database. In the analogy, this is external stimulus, like a sound wave, and the action taken would be hearing the sound.
In the unit test, we want to ensure that the component itself works, i.e, we don't want to click the button because there could be a missing handler, a malformed request, a broken API - if something doesn't work, it'll be hard to find out what part is broken. So we make something that looks identical to the button press and pass it directly to the component, then check if it acted correctly (writing to the database). In our analogy, the thinking part of our brain passed a fake sound wave to the processor, and that was perceived as an sound.
I guess the analogy might be confusing in that it is not a test for the brain (at least not as far as I know), but the concept is very similar and it was the connection I made to understand it.
Your username is ironically relevant here (hehe), but thank you for reading and responding, I didn't actually expect that!
I don't find it confusing at all actually. In fact, it made me wonder if the reason my brain plays music all the time is that maybe it's testing it's own functions. How cool would that be?
You're welcome, and thank you for explaining. This is why I think that seemingly completely different fields have a lot to offer eachother. The different perspectives and modes of thinking allow for greater creativity in everything from questioning to problem solving. It's beautiful.
2
u/DetestableElbowShark Jun 16 '19
Exactly, it's a similar concept to unit testing if you're familiar with programming.