Using Analog Discovery 2 with Behave Python Framework to do hardware test

[YTusername]

Hi

I made a quick overview of using Analog Discovery 2 as a testing platform to perform testing plans. I found this approach very easier and faster than developing testing platform circuit from zero.

https://atadiat.com/en/e-hardware-test-using-analog-discovery-2-with-behave-python-framework/

[tggzzz]

N.B. I have not assessed the behave DSL against the potential problems noted below.

It looks like the behave framework is yet another Domain Specific Language (DSL).

The important questions relate to the advantages and disadvantages of a DSL versus a library (containing the same functionality) written in a standard language. For the AD2, JavaScript would be a suitable language, since that is already available in the AD2 Waveforms software.

With a DSL you have to consider training someone to use the DSL, and that might mean creating training material. You can't just hire somebody off the street with the specific experience. With a DSL there are no toolsets, especially context sensitive editors and debuggers.  With most of the DSLs I've seen, the interaction between language features is poor. As time goes on and deficiencies are found, more features are added, and the result can end up as an unholy mess.

Using a standard language avoids those problems. With a halfway decent library, it is just as easy for a non-technical person to create simple "scripts" which just call the library functions.

So, while there can be valid uses for DSLs, IMNSHO usually libraries in standard languages are preferable.

If I was to use the AD2/Waveforms as a test platform (which is very tempting), I would investigate JavaScript first. I would only move onto a DSL once I found things that couldn't be done.

Background snipe: all hardware engineers dream of creating a processor. The software engineers' equivalent is creating a language+compiler

[YTusername]

Well to be more accurate, Behave is not a DSL. It's a Python framework that converts a DSL (if I can say so) to a general-purpose language, Python in our case.

Your testing script is a casual Python code, you just need to implement each human-readable sentence in you testing plan with a function.

I find the approach of using Behave beside the Python gives the best of both worlds. And in a later stage, it will really help you or even the non-technical guy to write test plans in an easy way and later implement them technically.

However, the big advantage still for using AD2 as a testing platform with its SDK in any suitable way you prefer.

[tggzzz]

I accept your points.

I question whether it is significantly easier in the long run to

• train one or more non-technical persons to use a limited DSL, or
• train them to use a very limited subset of a standard language

Any such very limited subset of a standard language would be simply calling your library functions with arguments containing the same information as they write in the DSL.

There's an old saying from the 1970s. If you make it possible program in English, you will find that people cannot think and write in English.