Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Relating Programming, Testing, Coding, and Checking

DZone's Guide to

Relating Programming, Testing, Coding, and Checking

The normal process of automating our development approach should include executing code flows in the application, checking results, and asserting on those checks.

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

Older computing books and papers have a lot of really useful information — read them. Programming has an easy-to-automate level called coding with a similar relationship to testing that checking has. Assert as well as check. Developing includes testing and programming and other stuff.

Here are some quick notes from a reading of the book Representation and Meaning, published in 1972, compiled from various academic papers from 1960—1965.

The first paper in the book The Heuristic Compiler by Herbert A. Simon contains the following quote at the start of Section 2.2:

One distinction between the restricted, relatively simple tasks we call “coding,” and the broader, more difficult tasks we call “programming,” is that the latter may encompass the selection or design of an appropriate problem representation, while the former does not.

Which made me think of the various discussion about testing vs. checking and automation — specifically, the following questions.

  • We can’t automate testing; we can automate checking.
  • Why don’t we talk about programming automation?

We Can’t Automate Testing; We Can Automate Checking

The quoted statement about coding and programming seems to have a similar relationship to statements about checking and testing.

  • Programming and testing:
    • Broader and more difficult than coding and checking.
    • Selection and design of appropriate problem representations.
  • Coding and checking: A representation of the work done when programming or testing.

Why Don’t We Talk About Programming Automation?

We don’t talk about programming automation because we automate coding:

  • Code completion.
  • Macro systems.
  • Annotations for code generation, i.e., projectlombok.
  • Transcompilers.

It almost seems abnormal to consider the act of coding without thinking of how we can automate it. We have been doing this to coding since we started coding.

My first major project was the generation of program code from JSP diagrams. In the course of that project, I automatically generated C and Cobol code.

The paper by Herbert A Simon referenced above describes an exploration of automating the programming tasks by treating it as a problem-solving exercise. The automation of coding was already a given and taken for granted.

A Diagram

I drew a diagram in my notes from reading the book:

I added some extra information to my diagram:

  • “…” to represent the fact that developing does not consist of only programming and testing.
  • Both programming and testing have levels of representation — the stuff we can easily automate and the stuff that humans do (which we find harder to automate).
  • We automate at the "easy" level.

And, for public consumption, I have tidied the diagram and added additional information:

  • “-” to represent the fact that every named "high-level set tasks" has a lower level (which may or may not have a name) of easy to automate tasks.
  • I added asserting into the checking representation because we check that a particular condition is met e.g. if(x==2){return false;} and we can report on the check in reports and monitoring. We assert on it to halt the execution of an automated process.

Summary

I try to develop a model of automating as part of the software development. This means I avoid thinking of test automation or automation and I think that allows me to think broadly about tool support in the development process than limiting it to testing or testers.

I think this makes it easier to communicate to people who identify with the role of programmer because we no longer talk about automating testing — we talk about extending the normal process of automating our development approach to include:

  • Executing code flows in the application.
  • Checking results.
  • Asserting on those checks.

Much value exists in the documentation trail of computing history. Seek it out. Do not ignore it.

References

  • Representation and Meaning: Experiments with Information Processing Systems, edited by Herbert A. Simon and Laurent Siklossy, published in 1972.
  • The Heuristic Compiler, by Herbert A. Simon (see here and ).

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
devops ,programming ,software testing ,automation

Published at DZone with permission of Alan Richardson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}