[Interest] Need advice to add tests to an existing, project

Thu Nov 9 15:36:01 CET 2017

On 11/08/2017 04:02 AM, Christian Gagneraud wrote:
> On 8 November 2017 at 13:35, Roland Hughes <roland at logikalsolutions.com> wrote:
> Back in the days of the VAX 11/750 all of that microcode (what it was called
> I know VACOS (VAcuum Cleaner Operated System) but I do not know VAX, sorry! ;)
This site has a picture, but pretty much everything else they list is wrong.
http://gunkies.org/wiki/VAX-11/750

A bit better write up. The first OS to run on it was VMS. Later there 
was Ultrix and other things.
https://en.wikipedia.org/wiki/VAX-11

VMS was and still is the operating system created by God.  When it 
posolutely absitivly __has__ to work it goes on VMS. VMS clusters (the 
only real clusters) now called OpenVMS clusters, have contiguous uptimes 
measured in decades. The vast majority of systems written for and still 
running on this platform were designed to run correctly long after the 
human race is extinct. That's not a joke. Most every nuclear power plant 
in the world, vast majority of steel and paper mills, any and every 
place a really bad thing will happen if a worthless PC OS was used.

If you search around you can find, it's either the Irish or the British 
railway system has been running for over 17 years of contiguous up time.

If you want to know how to program on it, you can find a copy of this:
http://theminimumyouneedtoknow.com/app_book.html
Actually, Dr. Dobb's decided that book is one of the few books which 
should be on every programmer's book shelf
http://www.drdobbs.com/tools/developers-reading-list/232500396?pgno=6

>
>> then) was on a cassette tape you turned the key to boot from. Whole menu of
>> diagnostics. Today we see a good number of systems returning to built in
>> test and calibration code.
> Yeah, that completely true. But I see these as "system test", not unit test.
> I don't think i want to run my system tests from QtC. Sounds like a click bait.
> You could argue, that using Boot2Qt with their qemu stuff, you could
> achieve that.
> But I still think it's the wrong abstraction level.
> A simulated Boot2Qt always runs in a x86 vm. It does boot the same
> embedded linux distro but it doesn't boot on the same virtualised
> hardware. I guess you could tweak the arch in Yocto, maybe... is it
> worth?
>
> Anyway, it's an interesting topic, for example are we talking factory
> site auto-tests (eg. flash) or customer site auto-test (eg. remote
> update)?
> How much HW can you emulate/simulate that will make your tests meaningful?
>

"All life is sacred" she uttered while eating a steak.

Sorry, your viewpoint reminded me of a snippet of a novel I've returned 
to working on and have been serializing in un-edited form on an authors 
blog.

http://www.interestingauthors.com/blog/fiction/my-orphan-pt-1/

It will be a few days yet before the characters have the discussion 
about "All life is sacred" and humans being forced to eat other things 
which were once living, therefore "all" has a rather scoped definition.

Here, your definition of "unit" is rather scoped. It's not your fault. 
If you actually went to college for programming (be surprised how many 
in this field never did) and you were taught real logic, without PASCAL 
as part of the course, you had instructors teaching you each function 
required a "unit test." This was college. You were learning and this was 
all you had to work with, the single function you had just written.

In there defense, from the 1970s through to the late 1980s, many, many 
programmers were writing either for commercial sale, or in-house use, 
"library" functions. When C finally came out there were, perhaps 
thousands, of C function libraries for sale during days of DOS. Screen 
libraries, indexed file IO libraries, "super functions," the list went 
on and on. Some of it would still be useful today if the companies which 
wrote them hadn't went out of business without OpenSourcing the license. 
Other exist only on 5.25" floppies few can even read. "The C-Users 
Journal" used to let you purchase 5.25" floppies of all kinds of code 
written by staff and contributors. All of it is long since gone. Some of 
it would still be useful today.

When it comes to the world of embedded systems, "unit" has a much larger 
meaning and for good reason. Take something like a patient monitor. Some 
little device which puts a user interface and some control software into 
a box which then includes:

1) A blood pressure cuff pump with pressure sensors
2) An SP/O2 finger clip unit with current sensors
3) A temperature unit.

There could be other things in the monitor as well, but let us just 
assume this set. Each of these things is a "unit." The bundling of all 
of them into one device is also a "unit." Why does this terminology matter?

Unitized parts.

Each "unit" has to endure some, potentially 7+ years long, clinical 
trial/testing process in a regulated environment. I don't remember the 
exact wording of the FDA training, but, the higher the potential for 
"adverse outcome" the more intense and lengthy the testing process. 
Putting that in simple terms, a surgical robot goes through way more 
testing that a computerized temperature monitor. Policy and procedures 
are in place everywhere to cross check wacky temperature, blood 
pressure, SP/O2, etc. readings manually which is why hospitals tend to 
have half a dozen temperature taking methods and still have scads of 
manually operated cuffs for your arm.

What _is_ important about all of this is the concept of "unitized 
parts." When assembling your patient monitor you make certain to utilize 
a unit for each reading which has already gone through the approval 
process. Now your unit, which is a front end for all of these other 
units and sends data back to one or more remote systems, just needs to 
prove itself and that it doesn't interfere with the other previously 
proven units.

Economies of scale are achieved by utilizing the same parts over and 
over across different products. You can only do that if each part is a 
fully tested unit.

While I will be the first to state:

Professionals Don't Use Microsoft Products

Microsoft attempted to do this with VBX controls. Things you dragged and 
dropped into your desktop application then tweaked a few settings on so 
they did what you wanted. They were supposed to be trusted units. 
Problem was the slipshod coding and AGILE practices turned most of them 
into randomly exploding bombs rather than trusted units.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171109/79561c20/attachment.html>