The Origin of Software by Means of Artificial Selection

The Origin of Software by Means of Artificial Selection

New video lesson #49 in the Modern Embedded Systems Programming course explores the vast subject of software testing.

The most important takeaway from this lesson is that the only way to create anything complex is to evolve it, and the winners of the software development game are those who evolve the software faster by applying better, smarter, and more effective testing techniques to eliminate more defects sooner.

This software evolution is guided by artificial selection, which requires building artificial environments to test the software.

This lesson gave you an idea about one such artificial environment for unit testing (a unit testing harness), but the general idea is similar for most such harnesses.

Newcomers to unit testing often need clarification as to what exactly is being tested. A first impression might be that testing only concerns the CUT (Code Under Test). But you must realize that all tests necessarily exercise the CUT and the test environment. Therefore, methodologies like Test Driven Development (TDD) recommend starting the process without a CUT. The purpose of this first failing test is really to test the environment.

And finally, when you start testing more systematically, you will accumulate many tests. On the one hand, such tests are valuable for checking that your software keeps working and that the new features don't break the old ones, which is called regression testing. On the other hand, tests are code, too, and the more code you have, the slower you can progress. The trick is to find the right balance and discard the less relevant tests. Keeping all tests forever is a mistake.

I like the new terminology- Artificial environment, if I understand correct we currently call it as unit test environment/infrastructure where we provide simulated inputs for CUT. In today’s embedded world CUT is more important as it integrates into larger systems. Great read.

Like
Reply

To view or add a comment, sign in

More articles by Miro Samek

  • Optimal Hierarchical State Machine Implementation

    Most embedded developers are familiar with the classic implementation strategies for finite state machines (FSMs):…

    6 Comments
  • Can an RTOS be really real-time?

    Ask the question What is an RTOS? and you will almost always get a definition along the lines of: "A real-time…

    52 Comments
  • Preemptive and non-preemptive event-driven embedded software

    #embedded #programming #event-driven #rtos #state-machine #actor-model In my "Modern Embedded Systems Programming"…

    9 Comments
  • Are you shooting yourself in the foot with stack overflow?

    Have you checked where in RAM your main stack is placed? Because chances are that it is at the top of RAM, as shown in…

    36 Comments
  • Still Using a Naked RTOS?

    If you're still building embedded applications with a traditional RTOS and naked threads, it's time to ask: Are you…

    37 Comments
  • Blocking == Technical Debt

    Blocking occurs every time a program waits in line for something to happen. For instance, the basic Arduino "Blink"…

    22 Comments
  • Low-Code?

    In my last lesson in the "Modern Embedded Systems Programming" series on Embedded.com, I discuss visual modeling and…

    1 Comment
  • Optimal state machine implementation in C

    In the fifth lesson in the state machine segment on Embedded.com, I introduce the state machine implementation in C…

    3 Comments
  • Cutting through the confusion with state machines

    If you search the Internet for “state machine,” you are likely to get a kitchen sink of results: from hardware…

    4 Comments
  • Are you still debugging with "printf"?

    The venerable "printf" is still the most popular debugging technique, but it has terrible real-time performance. If you…

    1 Comment

Explore content categories