[PYTHON] Eine Geschichte über den Versuch, den Testprozess eines 20 Jahre alten Systems in C zu verbessern

Einführung

Vor einiger Zeit habe ich 20 Jahre lang versucht, verschiedene Tests eines in C-Sprache geschriebenen Systems zu verbessern, daher werde ich ein wenig Wissen schreiben, das ich zu diesem Zeitpunkt habe.

• Vorsicht Da ich auf meinem eigenen Computer eine Umgebung erstelle, während ich mich an diese Tage erinnere, um Artikel zu schreiben, unterscheidet sie sich tatsächlich von der Umgebung und Version, die ich in der Praxis erstellt habe. Es gibt auch Code in diesem Artikel, aber es ist alles nur ein falsches Beispiel, an das ich gedacht habe, um den Artikel zu schreiben.

Testcode für Unit-Tests erstellen

Mit einem System, das seit 20 Jahren läuft, weiß niemand mehr, was es bedeutet, aber es gibt eine Reihe von Stellen, an denen das vorhandene Verhalten nicht geändert werden sollte.

Wenn Sie keine andere Wahl haben, als an einem solchen Teil zu arbeiten, sind die folgenden Methoden wirksam.

Schreiben Sie zunächst den Testcode für den vorhandenen Code. Und nachdem wir bestätigt haben, dass alle erfolgreich sind, werden wir die Funktion nach und nach erweitern. Auf diese Weise können Sie mit der Funktionsaddition fortfahren und gleichzeitig bestätigen, dass die neue Funktionsaddition die vorhandene Funktion nicht beeinträchtigt.

Es ist ein sogenannter ** Test zuerst **, aber in einer so konservativen Umgebung mit einer langen Geschichte führt das, was Sie in XP gesagt haben, zu verschiedenen Verzerrungen. Wir werden am Ende dieses Kapitels darüber sprechen.

Einführung von xUnit

Sie können Ihr Bestes mit Assert usw. geben, aber es ist besser, ein xUnit-Testframework wie CUnit zu verwenden.

• Dieses Mal wurde nur CUnit überprüft, aber es scheint, dass die folgenden Unit-Test-Bibliotheken für die C-Sprache für neuere Produkte verfügbar sind.

** Cutter ** (1.2.7 veröffentlicht am 13.09.2019 ist das neueste) https://cutter.osdn.jp/index.html.ja

** UNITY ** (v2.4.3 veröffentlicht im November 2017. Einige Commit-Historien sind 2019/10) http://www.throwtheswitch.org/unity https://github.com/ThrowTheSwitch/Unity

Es kann auch aus xUnit-Frameworks für C ++ wie CPPUnit getestet werden, diesmal wird es jedoch entfernt.

Warum benötigen Sie ein xUnit-Testframework?

Es ist besser, ein bekanntes Test-Framework zu verwenden, da es weltweit viele Beispiele für die Realisierung gibt und es bei Problemen hilfreich sein wird. Die Verwendung des bekannten Testframeworks erleichtert außerdem die Arbeit mit Jenkins.

Das [xUnit-Plugin] von Jenkins (https://wiki.jenkins.io/display/JENKINS/xUnit+Plugin) verfügt beispielsweise über eine Funktion zum Aggregieren der XML-Ausgabe des berühmten xUnit und ist einfach automatisch zu testen. Es ist möglich, die Ergebnisse von zu aggregieren.

CUnit CUnit ist ein Framework der xUnit for C-Sprache, das von gcc und visual c verwendet werden kann.

Wie man mit Visual Studio 2019 baut

Da es nur Lösungen aus den Epochen VS2008 und 2005 gibt, ist es alt und es werden Warnungen ausgegeben.

1. Öffnen Sie CUnit-2.1-3 / VC9 / CUnit.sln
2. Erstellen Sie CUnit.h basierend auf CUnit-2.1-3 / CUnit / Headers / CUnit.h.in. Die Unterschiede sind wie folgt.
3. Erstellen Sie in der Reihenfolge libcunit-> andere Projekte.

• Wenn Sie alle auf einmal erstellen und eine Fehlermeldung erhalten, überprüfen Sie die Projektabhängigkeiten. Wenn Sie die Anzahl der gleichzeitigen Builds des Projekts auf 1 setzen, können Sie auch normal erstellen.

** So überprüfen Sie die Anzahl der gleichzeitigen Builds eines Projekts in Visual Stduio 2019 ** Wählen Sie "Extras" -> "Optionen" aus dem Menü, um den Optionsdialog zu öffnen, und wählen Sie "Projekte und Lösungen" -> "Erstellen / Ausführen", um den entsprechenden Bildschirm anzuzeigen.

So erstellen Sie mit dem Befehl make

Das folgende Beispiel zeigt das Erstellen mit dem Befehl make unter der Umgebung von Windows 10 + Ubuntu 18.04. Sie können es grundsätzlich auf die gleiche Weise wie im folgenden Artikel erstellen, die Version ist jedoch 2.1-3.

** Unit Test des C-Programms mit CUnit ** https://qiita.com/muniere/items/ff9a984ed7e51eee7112

wget https://jaist.dl.sourceforge.net/project/cunit/CUnit/2.1-3/CUnit-2.1-3.tar.bz2
tar xvf CUnit-2.1-3.tar.bz2
cd CUnit-2.1-3
aclocal
autoconf
automake
./configure
make
make install

Fehlerbehebung

Kein Befehl automake oder autoconf

Führen Sie zur Installation Folgendes aus.

sudo apt-get install autoconf              

Wenn ich configure oder etwas ausführe, erhalte ich den Fehler "configure: error: install-sh, install.sh oder shtool kann in". "" ./ .. "" ./../ .. "" nicht gefunden werden.

Führen Sie den folgenden Befehl aus und beginnen Sie von vorne

autoreconf -i

"Fehler: Libtool-Bibliothek verwendet, aber 'LIBTOOL' ist undefiniert" ist während der Konfiguration aufgetreten

Installieren Sie libtool mit dem folgenden Befehl.

sudo apt-get install libtool

Wenn zur Laufzeit "Fehler beim Laden gemeinsam genutzter Bibliotheken: libcunit.so.1: freigegebene Objektdatei kann nicht geöffnet werden: Keine solche Datei oder kein solches Verzeichnis" angezeigt wird

Legen Sie die Umgebungsvariable LD_LIBRARY_PATH fest.

export LD_LIBRARY_PATH=/usr/local/lib

Wenn Sie es dauerhaft machen möchten, schreiben Sie es in .bashrc

Ausführungsbeispiel

Bei der Ausführung über die Konsole ist dies wie folgt.

#include <CUnit/CUnit.h>

int max(int x, int y) {
	if (x>y) {
		return x;
	} else {
		return y;
	}
}
int min(int x, int y) {
	/** bug  **/
	if (x>y) {
		return x;
	} else {
		return y;
	}
}

void test_max_001(void) {
	CU_ASSERT_EQUAL(max(5, 4) , 5);
}
void test_max_002(void) {
	CU_ASSERT_EQUAL(max(4, 5) , 5);
}
void test_max_003(void) {
	CU_ASSERT_EQUAL(max(5, 5) , 5);
}
void test_min_001(void) {
	CU_ASSERT_EQUAL(min(5, 4) , 4);
}
void test_min_002(void) {
	CU_ASSERT_EQUAL(min(4, 5) , 4);
}
void test_min_003(void) {
	CU_ASSERT_EQUAL(min(5, 5) , 5);
}

int main() {
	CU_pSuite max_suite, min_suite;

	CU_initialize_registry();
	max_suite = CU_add_suite("max", NULL, NULL);
	CU_add_test(max_suite, "test_001", test_max_001);
	CU_add_test(max_suite, "test_002", test_max_002);
	CU_add_test(max_suite, "test_003", test_max_003);

	min_suite = CU_add_suite("min", NULL, NULL);
	CU_add_test(min_suite, "test_001", test_min_001);
	CU_add_test(min_suite, "test_002", test_min_002);
	CU_add_test(min_suite, "test_003", test_min_003);
	CU_console_run_tests();
	CU_cleanup_registry();

	return(0);
}

Weitere Funktionen für ASSERT finden Sie weiter unten. http://cunit.sourceforge.net/doc/writing_tests.html

Bitte verlinken Sie auf libcunit.a, wenn Sie die Quelle kompilieren, auf der CUnit ausgeführt wird.

gcc unit.c  -Wall -L/usr/local/lib -lcunit -o unit

Bei der Ausführung über die Konsole ist dies wie folgt.

Wie man mit Jenkins arbeitet

Erfahren Sie, wie Sie CUnit-Ergebnisse in Jenkins übertragen.

XML im Testcode ausgeben

Ändern Sie den Code, um eine XML-Datei zu erstellen, die an Jenkins übergeben werden soll. Verwenden Sie bei der Ausgabe in eine XML-Datei CU_automated_run_tests und CU_list_tests_to_file anstelle von CU_console_run_tests.

/**Abkürzung**/
	/**Konsolenausgabe
	CU_console_run_tests();
	*/
	/**XML-Ausgabe**/
	CU_set_output_filename("./unit");
	CU_automated_run_tests();
	CU_list_tests_to_file();
	CU_cleanup_registry();
/**Abkürzung**/

Wenn Sie die obige Datei ändern, kompilieren und ausführen, wird die folgende XML-Datei erstellt, anstatt sie an die Konsole auszugeben.

• unit-Listing.xml
• unit-Results.xml

Weitere Informationen zum Ausführen von CUnit finden Sie weiter unten. http://cunit.sourceforge.net/doc/running_tests.html#overview

Lassen Sie Jenkins das XML-Testergebnis analysieren.

Installieren Sie xUnit Plugin in der Plugin-Verwaltung.

Fügen Sie in den Jobeinstellungen dem Post-Build-Prozess "xUnit-Testergebnisbericht veröffentlichen" hinzu und wählen Sie CUnit-2.1 aus.

Geben Sie unit-Results.xml für Pattern an.

Wenn Sie den Build ausführen, erhalten Sie das folgende Ergebnis:

Teststubs erstellen

Wenn Sie bei der Automatisierung von Tests nur das xUnit-Testframework ** vorbereiten und versuchen, es zu automatisieren, schlägt die Einführung häufig fehl. Entweder können Sie nur einfache Dienstprogrammfunktionen testen und sie sind veraltet, oder Sie schreiben am Ende komplexen Testcode, um die abhängigen Bibliotheken konsistent zu machen.

Angenommen, Sie haben eine Bibliothek 2, die von Bibliothek 1 abhängt (siehe unten).

Erstellen Sie beim Testen der Bibliothek 2 einen Stub zum Testen der Bibliothek 1, damit geeignete Daten zum Testen der Bibliothek 2 zurückgegeben werden. Selbst wenn Bibliothek 1 vom Netzwerk und der Datenbank abhängt, können Sie sie auf diese Weise in einen geeigneten Testzustand versetzen, ohne sie tatsächlich zu verwenden.

Beispiel für die Erstellung eines einfachen Stubs

Überlegen Sie anhand eines einfachen Beispiels, wie Sie einen Test für Bibliothek 2 schreiben, der von Bibliothek 1 abhängt.

Beispiel für Bibliothek 1

Bibliothek 1 hat die folgende Implementierung. Bereiten Sie eine Funktion namens add vor, die zwei Argumente akzeptiert und das Ergebnis des Hinzufügens zurückgibt.

static1.h

#ifndef STATIC1_H
#define STATIC1_H
extern int add(int x, int y);
#endif

static1.c

#include "static1.h"

int add(int x, int y) {
	return x + y;
}

Beispiel für Bibliothek 2

Bibliothek 2 hat die folgende Implementierung. In Bibliothek 2 wird die Verarbeitung unter Verwendung der Add-Funktion von Bibliothek 1 in der proc-Funktion durchgeführt.

static2.h

#ifndef STATIC2_H
#define STATIC2_H

#include "static1.h"

extern int proc(int x, int y, int z);

#endif

static2.h

#include "static2.h"

int proc(int x, int y, int z) {
	int a = add(x,y);
	return add(a, z);
}

Bibliothek 1 Stub

Erstellen Sie einen Stub anstelle von echtem Code. Die Verarbeitung dieses Stubs führt bei jeder Ausführung der Add-Funktion die folgende Verarbeitung durch. ・ Notieren Sie die Anzahl der Anrufe -Ausführung der im Testcode vorab registrierten Rückruffunktion

stub_static.h

#ifndef STUB_static1_H
#define STUB_static1_H
#include "static1.h"

typedef int (*pfunc_add_def) ( int x , int y );

typedef struct {

    int count_add;
    pfunc_add_def pfunc_add;
} stub_data_def_static1;
extern stub_data_def_static1 stub_data_static1;
#endif

stub_static.c

#include "stub_static1.h"
stub_data_def_static1 stub_data_static1;


int add ( int x , int y ) {
    ++stub_data_static1.count_add;
    
    return stub_data_static1.pfunc_add( x , y );
    
}

Beispiel für einen Testcode

Das Folgende ist ein Beispiel für die Ausführung der proc-Funktion durch Definieren der Rückruffunktion, die vom Stub der add-Funktion im Testcode ausgeführt wird.

#include <CUnit/CUnit.h>
#include "static2.h"
#include "stub_static1.h"

int test001_stub_add(int x, int y) {
	/** add()Stub. X und y zum Testen mit CUNIT**/
	if (stub_data_static1.count_add == 1) {
		/**Erster Aufruf**/
		CU_ASSERT_EQUAL(x , 10);
		CU_ASSERT_EQUAL(y , 5);
		return 15;
	}
	if (stub_data_static1.count_add == 2) {
		CU_ASSERT_EQUAL(x , 15);
		CU_ASSERT_EQUAL(y , 4);
		return 19;
	}
	CU_FAIL("Falsche Anrufanzahl von add");
	return -1;
}

void test001() {
	memset(&stub_data_static1, 0, sizeof(stub_data_static1));
	stub_data_static1.pfunc_add = test001_stub_add;
	int ret = proc(10, 5,4);
	
	/**Überprüfen Sie die Anzahl der Anrufe**/
	CU_ASSERT_EQUAL(stub_data_static1.count_add , 2);
	
	CU_ASSERT_EQUAL(ret , 19);
}


int main() {
	CU_pSuite suite;

	CU_initialize_registry();
	suite = CU_add_suite("stubsample", NULL, NULL);
	CU_add_test(suite, "test001", test001);
	CU_console_run_tests();
	CU_cleanup_registry();

	return(0);
}

Wenn die Stub-Funktion mehrmals aufgerufen wird, überprüfen Sie den Wert des Arguments, das der Stub erhält, basierend auf der Anzahl der Aufrufe, um den Wert zu bestimmen, den der Stub zurückgeben soll.

Automatische Erstellung von Stubs

Im vorherigen Abschnitt haben wir ein Beispiel für einen einfachen Testcode mit Stubs vorgestellt. Das nächste Problem sind die Kosten für die Erstellung von Stubs.

Es ist nicht unmöglich, es von Hand zu erstellen, aber wenn es in Bibliothek 1 eine große Anzahl von Funktionen gibt oder wenn sie häufig aktualisiert werden, kann es schwierig sein, sie von Hand zu ändern. Überlegen wir uns also, wie Stubs automatisch generiert werden.

Es ist im Grunde eine einfache Konvertierung. Daher kann jede Programmiersprache automatisch Stubs generieren. Wenn Sie jedoch Spaß haben möchten, wird eine Programmiersprache empfohlen, die die Vorlagenbibliothek und den C-Sprachparser verwenden kann.

Versuchen Sie, Stubs automatisch mit Python zu generieren

C-Sprachparser-Bibliothek

Sie können C / C ++ - Quellcode mithilfe von pycparser analysieren. https://github.com/eliben/pycparser

Beachten Sie, dass diese Bibliothek nur für Code funktioniert, der vom Präprozessor verarbeitet wurde. Verwenden Sie daher tatsächlich das Ergebnis der Ausführung des Präprozessors wie unten gezeigt für den zu analysierenden Quellcode.

gcc -E static1.h

Dieses Mal werden wir die vorkompilierte Header-Datei wie folgt analysieren.

Zu analysierende Header-Datei

extern int add(int x, int y);
typedef struct {
 int x;
 int y;
} in_data_t;
typedef struct {
 int add;
 int minus;
} out_data_t;
extern void calc(in_data_t* i, out_data_t *o);
extern int max(int data[], int length);

Beispiel zum Analysieren der Header-Datei

import sys
from pycparser import c_parser, c_ast, parse_file

# https://github.com/eliben/pycparser/blob/master/examples/cdecl.py
def _explain_type(decl):
    """ Recursively explains a type decl node
    """
    typ = type(decl)

    if typ == c_ast.TypeDecl:
        quals = ' '.join(decl.quals) + ' ' if decl.quals else ''
        return quals + _explain_type(decl.type)
    elif typ == c_ast.Typename or typ == c_ast.Decl:
        return _explain_type(decl.type)
    elif typ == c_ast.IdentifierType:
        return ' '.join(decl.names)
    elif typ == c_ast.PtrDecl:
        quals = ' '.join(decl.quals) + ' ' if decl.quals else ''
        return quals + _explain_type(decl.type) + '*'
    elif typ == c_ast.ArrayDecl:
        arr = 'array'
        if decl.dim: 
            arr = '[%s]' % decl.dim.value
        else:
            arr = '[]'

        return _explain_type(decl.type) + arr

    elif typ == c_ast.FuncDecl:
        if decl.args:
            params = [_explain_type(param) for param in decl.args.params]
            args = ', '.join(params)
        else:
            args = ''

        return ('function(%s) returning ' % (args) +
                _explain_type(decl.type))

    elif typ == c_ast.Struct:
        decls = [_explain_decl_node(mem_decl) for mem_decl in decl.decls]
        members = ', '.join(decls)

        return ('struct%s ' % (' ' + decl.name if decl.name else '') +
                ('containing {%s}' % members if members else ''))

def show_func_defs(filename):
    # Note that cpp is used. Provide a path to your own cpp or
    # make sure one exists in PATH.
    ast = parse_file(filename, use_cpp=False,
                     cpp_args=r'-Iutils/fake_libc_include')
    if not isinstance(ast, c_ast.FileAST):
        return

    for ext in ast.ext:
        if type(ext.type) == c_ast.FuncDecl:
            print(f"function name: {ext.name} -----------------------")
            args = ''
            print("parameters----------------------------------------")
            if ext.type.args:
                for arg in ext.type.args:
                    print(f"{_explain_type(arg)} {arg.name}")
            print("return----------------------------------------")
            print(_explain_type(ext.type.type))

if __name__ == "__main__":
    if len(sys.argv) > 1:
        filename  = sys.argv[1]
    else:
        exit(-1)

    show_func_defs(filename)

Als einfacher Ablauf des Analyseprozesses kann FileAST als Ausführungsergebnis von parse_file abgerufen werden. Durch Analysieren der ext-Eigenschaft dort können Sie die Informationen der in der Datei definierten Funktion abrufen. Das Ergebnis der Ausführung des obigen Programms und der Überprüfung der Funktionsdefinition in der Header-Datei wird wie folgt ausgegeben.

C:\dev\python3\cparse>python test.py static1.h
function name: add -----------------------
parameters----------------------------------------
int x
int y
return----------------------------------------
int
function name: calc -----------------------
parameters----------------------------------------
in_data_t* i
out_data_t* o
return----------------------------------------
void
function name: max -----------------------
parameters----------------------------------------
int[] data
int length
return----------------------------------------
int

Es wurde bestätigt, dass die C-Sprachquelldatei mit pycparser auf diese Weise leicht analysiert werden kann.

Vorlagenbibliothek

Beim Erstellen von Header- und Quelldateien für Stubs erleichtert die Vorlagenbibliothek das Erstellen. Die Vorlagenbibliothek in Python finden Sie im Folgenden.

** Ich möchte zum ersten Mal seit einiger Zeit HTML in Python ausgeben. Überprüfen Sie daher die Vorlage ** https://qiita.com/mima_ita/items/5405109b3b9e2db42332

Diesmal benutze ich Jinja2.

Code zum Erstellen von Stubs

Im Folgenden finden Sie ein Beispiel für die Implementierung eines Tools zur Stub-Erstellung mithilfe eines Parsers und einer Vorlagenbibliothek in C-Sprache.

create_stub.py

import sys
import os
from pycparser import c_parser, c_ast, parse_file
from jinja2 import Template, Environment, FileSystemLoader


stub_header_tpl = """
#ifndef STUB_{{name}}_H
#define STUB_{{name}}_H
#include "{{name}}.h"
{% for func in function_list %}
typedef {{func.return_type}} (*pfunc_{{func.name}}_def) ({% for arg in func.args %}{% if loop.index != 1 %},{% endif %} {{arg.typedef}} {{arg.name}}{{arg.array}} {% endfor %});
{% endfor %}

typedef struct {
{% for func in function_list %}
    int count_{{func.name}};
    pfunc_{{func.name}}_def pfunc_{{func.name}};
{% endfor %}
} stub_data_def_{{name}};
extern stub_data_def_{{name}} stub_data_{{name}};
#endif
"""

stub_source_tpl = """
#include "stub_{{name}}.h"
stub_data_def_{{name}} stub_data_{{name}};

{% for func in function_list %}
{{func.return_type}} {{func.name}} ({% for arg in func.args %}{% if loop.index != 1 %},{% endif %} {{arg.typedef}} {{arg.name}}{{arg.array}} {% endfor %}) {
    ++stub_data_{{name}}.count_{{func.name}};
    {% if func.return_type != "void" %}
    return stub_data_{{name}}.pfunc_{{func.name}}({% for arg in func.args %}{% if loop.index != 1 %},{% endif %} {{arg.name}} {% endfor %});
    {% else %}
    stub_data_{{name}}.pfunc_{{func.name}}({% for arg in func.args %}{% if loop.index != 1 %},{% endif %} {{arg.name}} {% endfor %});
    {% endif %}
}
{% endfor %}
"""


class ParameterData():
    def __init__(self, name, typedef):
        self.__name = name
        self.__typedef = typedef
        self.__array = ""
        if '[' in typedef:
            self.__array = "[" + typedef[typedef.index("[")+1:typedef.rindex("]")] + "]"
            self.__typedef = typedef[0: typedef.index("[")]

    @property
    def name(self):
        return self.__name

    @property
    def typedef(self):
        return self.__typedef

    @property
    def array(self):
        return self.__array

class FunctionData:
    def __init__(self, name, return_type):
        self.__name = name
        self.__return_type = return_type
        self.__args = []

    @property
    def name(self):
        return self.__name

    @property
    def return_type(self):
        return self.__return_type

    @property
    def args(self):
        return self.__args


# https://github.com/eliben/pycparser/blob/master/examples/cdecl.py
def _explain_type(decl):
    """ Recursively explains a type decl node
    """
    typ = type(decl)

    if typ == c_ast.TypeDecl:
        quals = ' '.join(decl.quals) + ' ' if decl.quals else ''
        return quals + _explain_type(decl.type)
    elif typ == c_ast.Typename or typ == c_ast.Decl:
        return _explain_type(decl.type)
    elif typ == c_ast.IdentifierType:
        return ' '.join(decl.names)
    elif typ == c_ast.PtrDecl:
        quals = ' '.join(decl.quals) + ' ' if decl.quals else ''
        return quals + _explain_type(decl.type) + '*'
    elif typ == c_ast.ArrayDecl:
        arr = 'array'
        if decl.dim: 
            arr = '[%s]' % decl.dim.value
        else:
            arr = '[]'

        return _explain_type(decl.type) + arr

    elif typ == c_ast.FuncDecl:
        if decl.args:
            params = [_explain_type(param) for param in decl.args.params]
            args = ', '.join(params)
        else:
            args = ''

        return ('function(%s) returning ' % (args) +
                _explain_type(decl.type))

    elif typ == c_ast.Struct:
        decls = [_explain_decl_node(mem_decl) for mem_decl in decl.decls]
        members = ', '.join(decls)

        return ('struct%s ' % (' ' + decl.name if decl.name else '') +
                ('containing {%s}' % members if members else ''))

def analyze_func(filename):
    ast = parse_file(filename, use_cpp=False,
                     cpp_args=r'-Iutils/fake_libc_include')
    if not isinstance(ast, c_ast.FileAST):
        return []
    function_list = []
    for ext in ast.ext:
        if type(ext.type) != c_ast.FuncDecl:
            continue
        func = FunctionData(ext.name,  _explain_type(ext.type.type))
        if ext.type.args:
            for arg in ext.type.args:
                param = ParameterData(arg.name, _explain_type(arg))
                func.args.append(param)
        function_list.append(func)
    return function_list


if __name__ == "__main__":
    if len(sys.argv) != 3:
        print("python create_stub.py vorverarbeiteter Header-Ausgabeordner")
        exit(-1)
    filename  = sys.argv[1]
    dst_folder  = sys.argv[2]
    function_list = analyze_func(filename)
    if len(function_list) == 0:
        print("Die Funktion konnte nicht gefunden werden")
        exit(-1)
    data = {
        'name' : os.path.splitext(filename)[0],
        'function_list' : function_list
    }
    #Erstellen einer Stub-Header-Datei
    with open(f"{dst_folder}/stub_{data['name']}.h", mode='w', encoding='utf8') as f:
        f.write(Template(stub_header_tpl).render(data))

    #Erstellen einer Stub-Quelldatei
    with open(f"{dst_folder}/stub_{data['name']}.c", mode='w', encoding='utf8') as f:
        f.write(Template(stub_source_tpl).render(data))

Die mit diesem Tool erstellten Stubs lauten wie folgt.

stub_static1.h

#ifndef STUB_static1_H
#define STUB_static1_H
#include "static1.h"

typedef int (*pfunc_add_def) ( int x , int y );

typedef void (*pfunc_calc_def) ( in_data_t* i , out_data_t* o );

typedef int (*pfunc_max_def) ( int data[] , int length );


typedef struct {

    int count_add;
    pfunc_add_def pfunc_add;

    int count_calc;
    pfunc_calc_def pfunc_calc;

    int count_max;
    pfunc_max_def pfunc_max;

} stub_data_def_static1;
extern stub_data_def_static1 stub_data_static1;
#endif

stub_static.c

#include "stub_static1.h"
stub_data_def_static1 stub_data_static1;


int add ( int x , int y ) {
    ++stub_data_static1.count_add;
    
    return stub_data_static1.pfunc_add( x , y );
    
}

void calc ( in_data_t* i , out_data_t* o ) {
    ++stub_data_static1.count_calc;
    
    stub_data_static1.pfunc_calc( i , o );
    
}

int max ( int data[] , int length ) {
    ++stub_data_static1.count_max;
    
    return stub_data_static1.pfunc_max( data , length );
    
}

Wenn der C-Sprachparser nicht verfügbar ist

Es gibt häufig Situationen, in denen Python nicht verfügbar ist oder der C-Sprachparser nicht verfügbar ist. Verwenden Sie in diesem Fall doxygen.

Doxygen kann die Quelldatei analysieren und die Funktionsinformationen in XML ausgeben. Es ist auch möglich, eine Datei für Stubs basierend auf dieser XML zu erstellen. Viele C- und C ++ - Sites verwenden Sauerstoff, daher ist dies wahrscheinlich ein geringeres Hindernis für die Einführung als die Verwendung von Python. * *

• Ich habe früher Stubs mit Doxyge + VBS gemacht.

Wie man andere Stubs erstellt und verspottet

Ich habe es nicht wirklich benutzt, aber es gibt andere Methoden wie folgt.

CMock https://github.com/ThrowTheSwitch/CMock Es scheint Code für Mock mit Ruby zu erstellen. Möglicherweise kann Ruby in der Umgebung verwendet werden.

** Ideen zur Verwendung von Stub-Funktionen in C-Sprachtests ** https://qiita.com/HAMADA_Hiroshi/items/e1dd3257573ea466d169 "So führen Sie einen Komponententest durch, indem Sie Funktionen in derselben Quelle stubben, ohne die vorhandene Quelle zu ändern", Grundidee Verwendet Makros, um vorhandene Funktionen durch Aliase zu ersetzen. Glücklicherweise musste ich keinen Test schreiben, um eine Funktion in derselben Quelle aufzurufen, also habe ich sie nicht wirklich verwendet.

Messmethode für die Abdeckungsrate

Wenn Sie einen Testcode schreiben, können Sie beurteilen, ob der Test ausnahmslos ausgeführt wird, indem Sie das vom Testcode abgedeckte Verhältnis messen. Glücklicherweise wird gcc mit einem Tool namens gcov geliefert, mit dem die Abdeckung gemessen werden kann.

10 gcov—a Test Coverage Program https://gcc.gnu.org/onlinedocs/gcc/Gcov.html

** Wie man gcov benutzt ** https://mametter.hatenablog.com/entry/20090721/p1

Beispiel für die Messung der Abdeckung

Messen wir die Abdeckung am Beispiel des zuvor verwendeten Stubs. Ändern Sie diesmal static2.c von Bibliothek 2 wie folgt, um absichtlich eine nicht erreichbare Route zu erstellen.

static2.c

#include "static2.h"

int proc(int x, int y, int z) {
	int a = add(x,y);
	return add(a, z);
}

int proc2() {
	/**Nicht erreicht**/
	return 0;
}

Kompilieren Sie dann mit der Option -coverage, um die Abdeckung zu messen.

gcc -c -Wall -Wextra static2.c -coverage
ar r libstatic2.a static2.o 
gcc -c -Wall -Wextra stub_static1.c
ar r libstub_static1.a stub_static1.o
gcc test.c -coverage  -Wall -Wextra -L. -lstatic2 -lstub_static1   -L/usr/local/lib -lcunit -o test

Durch Ausführen des obigen Befehls werden die folgenden Dateien erstellt.

• static2.gcno
• test.gcno
• test

Danach werden beim Ausführen von test die folgenden Dateien erstellt.

• static2.gcda
• test.gcda

Führen Sie den folgenden Befehl aus, um die Abdeckung von static2.c im Test zu überprüfen.

gcov static2.gcda 

Wenn dieser Befehl ausgeführt wird, wird die folgende Meldung angezeigt.

File 'static2.c'
Lines executed:60.00% of 5
Creating 'static2.c.gcov'

Hier können Sie sehen, dass die Abdeckung 60% beträgt. Um herauszufinden, wo sie nicht abgedeckt ist, zeigen Sie static2.c.gcov an. In diesem Beispiel können Sie sehen, dass proc2 nicht übergeben wird.

Andere automatische Tests

Über den Effekt

Wir beurteilen, dass es in den folgenden Punkten wirksam ist.

・ Das Risiko einer Funktionserweiterung ohne Änderung des Verhaltens der aktuellen Funktion kann unterdrückt werden.

• Durch Schreiben eines Testcodes können Sie die Funktionen klären, die bisher im Dunkeln lagen. ・ Durch Schreiben von Testcode können Sie Fehler erkennen, die in vorhandenem Code geschlafen haben. → Ob es behoben werden soll oder nicht, ist eine andere Sache. Ein Gleichgewicht zwischen der Häufigkeit des Auftretens, dem Grad der Auswirkung zum Zeitpunkt des Auftretens und den Korrekturkosten.

Es gibt jedoch einige Probleme. Betrachten wir sie daher im nächsten Abschnitt.

Was ist mit der SQL-Prüfung?

In einer älteren Umgebung müssen Sie möglicherweise SQL in den Quellcode schreiben und es tatsächlich mit einer Datenbank verbinden und zum Testen ausführen. In diesem Fall ist es wünschenswert, den von jedem Entwickler verwendeten DB-Bereich zu teilen und einen Komponententest durchzuführen.

In einer großen Organisation gibt es jedoch Abteilungen, die sich auf DB spezialisiert haben, und es ist nicht einfach, die Datenbank zu manipulieren. Wenn Sie die Datenbank selbst in die lokale Umgebung stellen, wird ein schlechter PC zu einem Engpass, oder selbst wenn Sie ihn durchbrechen, wenn Sie die Verwaltung der Datenbank in Ihrer persönlichen Umgebung belassen, verwenden einige Entwickler weiterhin die alte Umgebung. Es besteht auch die Gefahr, dass dies geschieht.

In einem solchen Fall können Sie mit einer weniger bewussten Methode des Zurückrollens umgehen, wenn der automatische Test beendet ist.

① Starten Sie den automatischen Test ② Starten Sie eine DB-Transaktion ③ Speichern Sie die Testdaten in der DB ④ Führen Sie einen automatischen Test durch ⑤ Überprüfen Sie anhand des Ergebnisses des automatischen Tests, wie sich die Datenbank geändert hat ⑥ DB-Rollback

Diese Methode ist keine perfekte Idee, aber einfach zu implementieren.

Massive Kombinationstests

Wenn Sie den Eingabewert und den erwarteten Wert in das Array von Strukturen schreiben, können Sie viele Tests durchführen. Eine der am häufigsten verwendeten Methoden besteht darin, eine Liste der Ein- und Ausgaben in Excel zu schreiben, sie mit VBA-Makros in ein Array von C-Sprachstrukturen zu konvertieren und in den Testcode zu schreiben.

Verzerrungstest zuerst in einer konservativen Wasserfallumgebung

Wenn die Methode in einer konservativen Wasserfallumgebung verwendet wird, werden nach Abschluss der Implementierung die Testspezifikationen und Checklisten für Komponententests erstellt und getestet. Wenn Sie jedoch als Erstes einen Test durchführen, ist die Implementierung abgeschlossen = der Komponententest ist abgeschlossen, sodass hier Verzerrungen auftreten.

Plan kommt nicht auf die traditionelle Linie

Bei der herkömmlichen Methode wird die Einteilung in drei Schritten beschrieben: Implementierung, Erstellung einer Checkliste für den Komponententest und Implementierung des Komponententests. Und mit einer hoch kontrollierten, vollständigen und perfekten Organisation ist jeder Prozess genau zeitlich abgestimmt.

Wenn Sie zuerst einen Test durchführen, können Sie den Komponententest nicht von der Implementierung trennen, sodass die individuelle Arbeitszeit nicht gemessen werden kann, und Sie werden ihn separat melden.

Unit-Test-Spezifikationen

Es muss entschieden werden, was mit den mit der herkömmlichen Methode erstellten Unit-Test-Spezifikationen und Checklisten geschehen soll. Es wäre schön, wenn wir entscheiden könnten, dass die Codeüberprüfung des Testcodes in Ordnung ist und dass das Produkt des Komponententests der Testcode ist, aber in einer älteren Umgebung sind Dokumente wichtig. In diesem Fall müssen Sie aus dem Testcode eine Testspezifikation oder eine Checkliste erstellen.

Die erste Gegenmaßnahme besteht darin, den Inhalt des Testcodes manuell auf die Checkliste zu übertragen. Das Problem ist, dass der Testcode und die Testspezifikationen nicht mehr synchron sind. Diese Methode ist auch eine sehr schlechte Antwort, die den Vorteil der automatischen Ausführung von Tests beseitigt. Sie wird jedoch häufig angewendet, da dies jeder tun kann, wenn es Zeit braucht.

Die zweite Methode besteht darin, aus dem Kommentar des Testcodes eine Testspezifikation zu generieren. Beschreiben Sie den Inhalt des Tests im Kommentar des Testcodes und fassen Sie die von Doxygen usw. extrahierten Ergebnisse in der Checkliste zusammen. In diesem Fall besteht die Gefahr, dass zwischen dem Kommentar und der tatsächlichen Verarbeitung eine Diskrepanz besteht.

Die dritte Methode besteht darin, Japanisch zu schreiben, das sich nicht seltsam anfühlt, selbst wenn es in die Checkliste für den im Testcode angegebenen Testnamen ausgegeben wird.

	CU_add_test(max_suite, "max(a,b)Um a=5,b=Bestätigen Sie im Fall von 4, dass der Wert von a erhalten wird", test_max_001);

Wenn Sie den Test mit der obigen Beschreibung ausführen, wird Folgendes in die XML-Datei des Testergebnisses ausgegeben.

Geben Sie danach die XML-Checkliste aus und Sie sind fertig. Das Problem bei dieser Methode besteht darin, dass der Inhalt der Checkliste groß wird, da die von CU_ASSERT_EQUAL usw. durchgeführten Prüfinhalte nicht in XML ausgegeben werden.

Die vierte Methode besteht darin, eine Funktion zu erstellen, die CU_ASSERT_EQUAL usw. umschließt, und innerhalb dieser Funktion den Inspektionsinhalt in einer Datei in einer Form auszugeben, die einfach in die Checkliste ausgegeben werden kann.

Unabhängig davon, für welche Methode Sie sich entscheiden, beachten Sie, dass das Festhalten am Dokument problematisch sein kann. → In einer Kultur, die am Schreiben festhält, stellen wir sicher, dass solche Arbeiten in der Schätzung enthalten sind.

Behandlung von Fehlerrutschen in Unit-Tests

Da der Komponententest nach Abschluss der Implementierung abgeschlossen ist, kann der Fehler im Komponententest nicht ausgelöst werden. Eine stark kontrollierte, vollständige und perfekte Organisation kann sich jedoch auf die Anzahl der Unit-Test-Fehler konzentrieren. In diesem Fall wird das Problem, das während der Implementierung aufgetreten ist, angemessen als solcher Fehler behoben.

Die Theorie, die sein sollte, ist zu überzeugen und neue Regeln zu schaffen, aber ich denke, es ist unmöglich, weil die Kultur anders ist.

Die Ziffern der Anzahl der Tests ändern sich, sodass herkömmliche Indikatoren unbrauchbar werden

Die Einführung automatisierter Tests ermöglicht die mechanische Verarbeitung einer großen Anzahl kombinatorischer Tests. Infolgedessen ist die Anzahl der automatisch durchgeführten Tests größer als die Anzahl der nach dem herkömmlichen Verfahren durchgeführten Tests. (Das ist eine Größenordnung)

Bisher betrug die Anzahl der Punkte auf der Checkliste, die höchstens Hunderte betrug, normalerweise eintausend oder zehntausend. Es ist eine Geschichte über "Was ist falsch daran, viele Tests durchzuführen?". Wenn es sich jedoch um eine stark kontrollierte, vollständige und perfekte Organisation handelt, wird sie als Ausreißer behandelt. Passen Sie daher die Granularität entsprechend an und verwenden Sie sie für die Berichterstellung. Möglicherweise muss die Nummer auf diesen Wert eingestellt werden.

Wenn Sie geeignete Maßnahmen ergreifen möchten, empfiehlt es sich außerdem, einen neuen Index als separate Tabelle für den automatischen Test zu erstellen.

Da die Anzahl der Fehler nach dem Integrationstest geringer ist als zuvor, wird er als Ausreißer behandelt.

Wenn Sie einen umfassenden Komponententest durchführen, haben Sie keine Probleme mit dem Integrationstest.

Dies ist ein Problem damit. Nehmen wir zum Beispiel an, Sie hatten in der Vergangenheit Dutzende von Fehlern, aber die Anzahl der Fehler ist fast verschwunden. Wenn Sie sich nur die Zahlen ansehen, müssen Sie sich fragen, ob die Perspektive des Integrationstests falsch ist.

Viele Leute wollen keinen Testcode schreiben

Wie ich unten schrieb, ist es das, was es ist. Lass uns aufgeben.

** Automatisierung von Unit-Tests mit unbewusstem Visual Studio ** https://qiita.com/mima_ita/items/05ce44c3eb1fd6e9dd46

Es ist möglich, die Wirkung des automatischen Tests durch Arbeitskräfte und Qualität zu erklären, ihn in einen Geldbetrag umzuwandeln, ein Gefühl der Krise zu wecken und Lehrmaterialien vorzubereiten, aber ehrlich gesagt ist es eine Kultur, die nicht verstanden werden kann, egal wie viel sich eine solche Geschichte ansammelt. Funktioniert überhaupt nicht ** ** </ font>.

sudo apt-get install cppcheck

$ cppcheck --enable=all .
Checking cov.c ...
1/7 files checked 14% done
Checking main.c ...
2/7 files checked 28% done
Checking static1.c ...
3/7 files checked 42% done
Checking static2.c ...
4/7 files checked 57% done
Checking stub_static1.c ...
5/7 files checked 71% done
Checking test.c ...
6/7 files checked 85% done
Checking unit.c ...
7/7 files checked 100% done
[cov.c:7]: (style) The function 'bar' is never used.
[static1.c:7]: (style) The function 'calc' is never used.
[static2.c:8]: (style) The function 'proc2' is never used.
(information) Cppcheck cannot find all the include files (use --check-config for details)

cppcheck --enable=all --xml --xml-version=2 ~/libsample/. 2>cppcheck.xml