Unit Tested System As Mythological System

In Chapter 4 of RefactoringImprovingTheDesignOfExistingCode MartinFowler writes, "This is not helped by the fact that most people have never learned to write tests or even to think about tests." This page is intended as a small contribution to thinking about testing.

UnitTesting seems to make a separation between the following concerns: what the unit is to do, and how the unit does that. We code the what as a unit test and the how as the unit. Additionally, we have a third concern: to know that the unit works. It seems that unit tests communicate this to the developer when executed.

Consider the following diagram, where how is associated with the unit and what is associated with the unit test (italicised text is something you can think or say, and the text in bold square brackets is something you can read in a file):

[finding lost image...] h ttp://www.appropriatesoftware.net/images/TestingMythology?.gif

We can recognise similarities between the form of the above diagram and the form of mythology described by RolandBarthes in his book Mythologies. Perhaps we can develop an understanding of our engineering practice within a general science, "coexistent within linguistics, which is semiology."

Is it ok to consider the unit as coding the implementation design intention (the how)? If so then it must be ok to borrow vocabulary from semiology and to say that the unit signifies the implementation design intention. In fact, we can identify three terms: a signified (the system design intention), a signifier (the unit), and the sign (the "implemented functionality", or "something may work").

Then in the same way, if we consider the unit test as signifying the requirement being satisfied by the system design intention, we can identify three more terms: a second signified (the requirement), a second signifier (the unit test), and a second sign (whether the "functionality works", or not).

Now, because the test sign makes use of the unit sign we have (what Barthes calls) a double semiological system. Myths are double semiological systems, but not all double semiological systems are myths. So, what does RolandBarthes say makes a myth special?

If my memory of Barthes is correct, the diagram you're using above more generally speaks about signs, but not necessarily mythologies. Mythology, in Barthes' formulation, is a bourgeois belief that attains its power by masquerading as CommonSense and therefore above questioning. Signs in general are value-neutral; mythologies are hegemonic.

...agreed! It does speak about signs, and not necessarily about myths. I try to deal with belief and hegemony below. I'm not sure I came across the invocation of CommonSense within Barthes writing, but he seems to think that they achieve their power through the plausibility they present by distorting the nature of the sign that is reused within the myth. In this way they depend upon the existence of this sign. Shall we say that this sign exists within CommonSense? I'm sure AntonioGramsci? would nod us on. There seems to be a corresponding distortion constructed by a unit test suite which tells us something of the system, but never its true nature (TestsCantProveTheAbsenceOfBugs). This similarity (of distorted communication) and this difference (that it is not in fact an oppresive bourgeois myth) is what I'm trying to figure through here :-) -- JohnBywater

Semiotics always get tricky when you're dealing with software, anyway, because ultimately it's all just bits -- like MarshallMcLuhan said, "The electric light is pure information" -- and its reality is extremely contingent on its context. Viewed in emacs, a Perl script is just a text file; executed on the command-line, that script actually does things. The line between signifier and signified is fuzzy and contingent. (See also: TechnoShamanism?) -- FrancisHwang

...but written words are just letters; spoken words are just phonemes. The letters will run if the ink is water soluble and I spill tea all over the page; the phonemes resonate everything that is within range. DeleuzeAndGuattari? (amongst others) talk about the book as being a machine, that is the signifiers themselves (words in a sentance, sentances in a paragraph, paragraphs in a chapter, etc) constitute a machine. I'd say they are being metaphorical. However the signifiers when writing software (identifiers in an expression, expressions in a statement, statements in a unit, etc.) are part of a real machine. I think the advice to have methods, classes, etc. doing one thing well reflects this underlying nature of (human readable?) software code. If we try to make our code more expressive as we refactor, as KentBeck suggests does help--to move towards there being a good name for something that does one thing well--then can we not think in terms of code fragments as signifying intentions? I suppose by definition the line connecting signifier and signified is clear and only dependent on changes to either the intent or to the implementing code, but then there would be something new. This would be true regardless of scale, or complexity, or usage.

I saw a mechanical device once in an exhibition that implemented the mathematical concept "square root." It was facinating because there seemed to be something conceptually upsidedown about the thing. Now I can see that the mechanical system literally signifies the conceptual moving parts required to generate a square root. We can do it in our head, but we can write the process out as a machine to facinate people. Does the abacus do the same for integers? The fact that when programming we are in abstraction stratosphere shouldn't phase us. Perhaps because we are used to being "part of the machine", rather than the machine being part of us that we find ourselves oriented to think that our thoughts represent the machine, rather than that the machine represents our thoughts? Hmmm... -- JohnBywater

The signifiers in software are part of a real thing, to be sure, but their relationship to what they signify is defined by context, to a much greater extent than most signifiers. Words, for example, have limited meanings because they're parsed in limited ways. The word "tree" only has a few meanings (the common botanical tree, family tree, binary tree) and it's usually easy to figure out which meaning it is, in context. But imagine I hand you a file and don't tell you what format it is: What does it signify? A spreadsheet? A Perl script? It could even signify more than one thing: A steganographic file could be both a jpeg of a Playboy centerfold and an encrypted message about making a nuclear bomb.

At any rate, John, part of me thinks this is provocative but part of me wonders how it's possibly relevant to my life, as a programmer or even just as a person. Especially since I don't really believe in an essential nature of things outside of human observation, and I already consider myself to live in a universe where everything is only a signifier for something else. -- francis

Thanks Francis.

From the first paragrah, I feel that just because one signifier can be used to signify many signifieds, and just because one signified can have many signifiers, doesn't affect a consideration of one of these associations. I can't read chinese. If I was given some chinese I would not know whether it was instructions to read Playboy, or instructions to make a nuclear bomb. The same goes for a UML diagram: you don't really understand it unless you can confidently associate meaning to the elements of notation and the names given to instances of these elements. It's language, right? It's created within a context for a reason and at some time, and these can change. Digital logic, which has changed over time, started when somebody managed to represent the concept of a two state switch (coded as transistor, but also as other things). The elementary concept of storage of such state is coded (not exclusively) by reusing our switch several times, perhaps to create a jk flip-flop. The concept of more complex storage (like representing a larger numbers) can be constructed by reusing the code for simple storage. We create a register from many flip-flops. But we use the flip-flop sign (the total of our understanding and our device) as a means to code the intention for complex storage (the register). And so on until by the time we get to Perl we are really in abstraction stratosphere, it really makes sense if you start to read LearningPerl. How else would it? But the principle, that we are directly coding our concepts as devices, remains. And we normally make larger devices out of small devices. Of course these relationships are contingent upon them being redesigned, or reconsidered, but these instabilities are secondary, and out of our control.

On the personal note, I think the reason I have been thinking about this is because I feel that I have been asked to design solutions for products where the limiting problem was the broken organisational devices within which I was working. Check Dilbert. Why can he not redesign his environment? There is only a slight difference between design of software and design of how to do software. I've been thinking that perhaps the reason software is in the Stone Age (quote from the AntiPatternsBook) is because the people doing software were not able to redesign their processes. XP seems to represent a break from this norm, and to offer a potent alternative. I just feel like XP was designed by somebody who redirected good OO design considerations onto their process. If everything was fine in the World we would have no work to do. However there seems at least to be a problem within working that inhibits working. I, as a worker, seem to be encouraged to redesign some corporate system, but not how I'm managed, or how anything else is managed, organised or conducted. Our 'democracies' for example. That these things are, as you say, just signs means that they can be subjected to exactly the same design consideration as some corporate product, or an instance of doing XP. So this is the relevance and the motivation: just as the New Citroen (back to Mythologies) is created by engineers and artists and then appears as a smooth piece of magic, so bourgeois society presents itself as a piece of magic, and certainly not as something we should be able to fix up when broken. What's it meant to be doing anyway? Does anybody really know these days? The xUnit frameworks seems to signify the fixing of a broken process (getting to knowing that the system does what we want) and hence constitues a real transition away from the contradiction of externally organised cooperation and towards a state where "workers become the mechanics of society" (to quote HardtAndNegri? writing in Empire).

Francis, you live in NewYorkCity, right? What can we say about all the designs that are being submitted to CNN about the WorldTradeCenter site? Doesn't this indicate that there is a general desire to contribute considerations to this building, and doesn't the level of passion indicate that people don't have confidence that the official design will work for them.

Because we need to design the means of designing, and produce the means of producing, we need to understand something of the nature of designing and producing. Design is immaterial production, and is essentially discursive. Knowing that a design works also requires an element of production, and I think it is interesting to realise that this second production is comparable, but essentially different from, the common myths that prevent us (for well known reasons) from realising the full scope of designing: that we can redesign everything!

I don't dispute the need to understand how design works, but I just have a problem with a seriously academic approach. My instinct, these days, when faced with a new domain in which people know very little, is not to search for some grand overarching set of principles to apply to them, but to be very pragmatic and low-level. I believe in admitting you know almost nothing, then starting with the little that you do know. Such an approach leads you to bottom-up sorts of approaches -- in programming, then, you have simple little maxims like OnceAndOnlyOnce and slightly more complex things like DesignPatterns. Nothing I have read or heard about Gramsci, DeleuzeAndGuattari?, Barthes, or HardtAndNegri? would lead me to believe that their stuff is useful in my goal, which is to get stuff done. Those names are primarily names used by academics whose jobs it is to theorize. My job is to do stuff, quickly and simply. -- francis

Yeah, I know. I don't want to be seriously academic(!), I do look to be as simple as possible, I have no concept that you can dream up solutions from nothing but thought and in isolation, I try to avoid the FalsePoliticalEconomyOfAcademia?, and I see alternatives to bottom-up approaches mostly fail the "beneficiaries". I agree with you really. But I think, above all, I want to be free! But I don't want to end up being free from being free: so I must be responsible for something! So is it of no value to grasp something of the processes that already involve us, and that require our involvement to be any good? Perhaps all this is in fact motivation, partly capability, to DoTheRightThing. At least every now and again anyway ;-)

When I learned to play the viola I also learned some theory, which didn't seem to have anything to do with playing at the time. But it really gave a touch of structure and did help. Practices are informed by consideration. Aren't considerations theoretical, in the broad sense of communicating some model? As you said, the thing perhaps is to consider whether something works, rather than whether something is correct. A philosophy of pragmatics, as DeleuzeAndGuattari? said in AThousandPlateaus. I suppose the only value in the above diagram would be informing somebody's understanding of UnitTesting. I found, after explaing the diagram's boxes to a few people, if I asked which way round they should visit the boxes, given you must start with the requirement "What works", after about a minute of thinking what it means to go between the different boxes, everybody saw that CodeUnitTestFirst looks a simpler route to having both pieces of code. It seemed fairly simple really. It doesn't tell them that they need to think about unusual input, or other things they may need to do, but it simply organises the whole. If UnitTesting is a pattern in some sense, then ChristopherAlexander says that we should be able to draw a digram. Isn't the above diagram this, from one view point at least? -- john

I have to agree with Francis. Some essential mythological elements are missing here. Stories (historical or fictional) are the prime means for informing social groups. Rituals describe and prescribe repeated and shared action-frames with focused intent. Symbols help provide the focus. I would say unit testing is ritualistic to some extent, but only as part of a larger mythological system. -- ChrisSteinbach

..I'm not so sure that stories and rituals are part of Barthes mythological schema, but your symbol may be the same as Barthes' sign. However, it would seem as though we generate stories to communicate things and rituals to do things. I come back to this below. -- JohnBywater

You may be right. I'm persuaded that I should take a look at semiotics in any case. --cs

To be clear, I'm not saying that unit testing is a mythological system. My method is to compare an understanding of Barthes' mythology, a specific category within semiology which I'll attempt to summarize as I go, with unit testing, a specific practice within software engineering. In a way, I'm hard casting "unit testing" as "mythology" in order to find similarity, and more interestingly, possible points of departure.

Firstly, Barthes refers to mythology as speech, or communication. The message may be believed, and may be hegemonic in its immanence. Of course, bourgeois culture, myths and all, constitute a hegemony. But this hegemony, with its contradictions, presents us, as KarlMarx said, as "a mere point of transition."

But does not a unit test suite communicate something to us ("that it works") - a message which may be believed, but also which may not? Additionally, hegemony need not be oppressive. Perhaps AnonioGramsci? spoke so much about bourgeois cultural hegemony because culture is one battleground within which class warfare is conducted. Is not unit testing itself aquiring an overarching position, a hegemony, within software engineering? It has within my practices, and is becoming so within the company I work for.

Indeed, it seems, given Barthes' warning that there must be no denouncement of the essential enemy (the bourgeois norm) without a rigorous methodology, that he devised his schema of mythology for a specific purpose: as a device for the denouncement of bourgeois culture.

I have no such purpose.

The UnitTestFramework? was devised for a different purpose: as technology for announcing "that it works."

todos:

how is like a myth?

what is a myth?

why is this interesting? how does it help engineering software?

in which order do we visit the boxes? what are the consequences of this choice?

this is the nature of knowing that it works: it is a myth that it works!

this myth has value, it communicates something we want to know, even if it "distorts" that about which it speaks

However all myths are produced for reasons with in social relationships: interestingly, perhaps uniquely, the 'mythological' system of unit testing is produced for self-informing consumption (both on the level of pattern, and on the level of test suite instance), rather than being externally produced, and oppressive. Does unit testing signify, by its creation and by its usage, a more general movement towards a mythology of reason that parallels the movement away from the contradiction of externally organised co-operation that characterises modern, or factory, production?

...more later...

"There seems to be a corresponding distortion constructed by a unit test suite which tells us something of the system, but never its true nature..."

Can you tell us something about the character and function of this distortion? --cs

I'll certainly try my best. :-) Chris, do you know whether it is accepeptable to put quotes into Wiki from printed books? Hope it's ok to come back to this over the next week or so.

The character of the distortion is that we receive a message about the system that tells us something of the system, but not everything, and nothing that is absolutely true: the tests tell only us what they have been coded to tell us! The function of the distortion serves our desire to know something of the nature of the system (what it should do, and whether it works). Speaking about something always represents something, and immediately (unavoidably) distorts the nature of what it talks about. The essence of our desire to know requires us to be interested in the design of distortion; in its production.

I think I'm trying to get round to the concept of a "mythology of reason" and "the idea which unites all others, the idea of beauty" (which will involve revisiting some of ChristopherAlexander's ideas).

From GeorgWilhelmFriedrichHegel's OldestProgramOfaSystem...

"First I will here speak of an idea, which, as far as I know, has not occurred to anyone - we must have a new mythology, but this mythology has to serve ideas, it has to become a mythology of reason."

So I'm not saying that this time (the case of UnitTesting) the distortion is a BadThing. No! It necessarily occurs as soon as we speak about the system! Just as I distort the nature of a rose by using it to signify my passion (or the nature of 'democracy' by speaking about 'freedom'), so I distort the nature of the system-under-test by speaking of the system with unit tests. The fresh aspect of UnitTesting, at least in the technically efficient form of TestDrivenDevelopment, the aspect I guess am trying to draw attention to, is that I design the distortion for my own purposes, rather than being presented with a distortion for somebody else's purposes. And then it apppears as truth! (See perhaps AllModelsAreWrongSomeModelsAreUseful.)

Then, on my way home, I wonder what other speach about whether things are working exists? Who were the designers? What did they intend with this speech? How did they know what I would need to know?

An example: http://www.krusch.com/real/public.html

I'll have to get back to this cos I'm no prof. and need to do a bit of work to make GoodSense?!

I understand. But I would say the distortion (if you like) works two ways and is more like a dialogue between test code and unit. Each forces the other into greater clarity and articulation. --cs

Sure! Perhaps it's at this point that the value of producing the technological 'myth' is realised: when the tests inform us that we need somehow to change the units. I'm reminded of ListenToTheCode, especially the 'strange loop' :-) Within a social 'machine', associated myths may tell us change to our rituals or stories, organisational 'devices' or cultural objects, is needed. (I wonder how this 'strange loop' appears within WikiStoneSociety? I'll have a look and see. How would we know whether Wiki needs fixing? How do we know what to fix?) What do/don't we want to know about?

But we can see a directionality: we intend that the tests tell us about the units, the units aren't intended to tell us about the tests, they are only intended to implement the functionality they are responsible for. --jb