Skip to main content
Getting Started with TESSY: Install, Import C Module, First Test Case, Coverage Report in 15 Minutes, featured image

Getting Started with TESSY: Install, Import C Module, First Test Case, Coverage Report in 15 Minutes

GSAS Engineering · · 5 min read

Getting Started with TESSY: Your First Test Case and Coverage Report in 15 Minutes

The fastest way to evaluate a unit testing tool is to use it on your own code. This guide walks through the TESSY workflow from installation to first coverage report, using a simple C module as the example. By the end, you will have created a test case, executed it, and viewed the MC/DC coverage report.

Razorcat TESSY is available as an evaluation license through GSAS Micro Systems. Contact us at the end of this article to request one.

Step 1: Install TESSY

TESSY runs on Windows (the primary platform for embedded development in India). The installation is a standard Windows installer:

  1. Run the TESSY installer
  2. Activate the license (node-locked or floating, provided by GSAS)
  3. Configure the compiler, point TESSY to your installed cross-compiler (Arm Compiler 6 via Keil MDK, IAR, TASKING, HighTec, or GCC)

The compiler configuration is the critical step. TESSY uses your project’s compiler to build test harnesses, so the test code compiles with the same toolchain as your production firmware. For teams in Bengaluru using Arm Keil MDK, point TESSY to the Arm Compiler 6 installation directory. For teams in Pune using TASKING for AURIX, point to the TASKING VX-toolset directory.

Step 2: Create a TESSY Project

Open TESSY and create a new project. The project stores all test configuration, test cases, and results. Specify:

  • Project name: typically matching your firmware project name
  • Compiler: the cross-compiler configured in Step 1
  • Include paths: the header file directories from your firmware project
  • Preprocessor defines: any project-level defines (e.g., TARGET_STM32F4, AUTOSAR_CLASSIC)

For this tutorial, we will use a simple temperature monitoring module:

// temp_monitor.h
##define TEMP_WARNING  80
##define TEMP_CRITICAL 100

typedef enum {
    TEMP_NORMAL,
    TEMP_WARNING_STATE,
    TEMP_CRITICAL_STATE
} TempStatus;

TempStatus evaluate_temperature(int current_temp, int rate_of_change);
// temp_monitor.c
##include "temp_monitor.h"

TempStatus evaluate_temperature(int current_temp, int rate_of_change)
{
    if (current_temp >= TEMP_CRITICAL || 
        (current_temp >= TEMP_WARNING && rate_of_change > 5))
    {
        return TEMP_CRITICAL_STATE;
    }
    else if (current_temp >= TEMP_WARNING)
    {
        return TEMP_WARNING_STATE;
    }
    else
    {
        return TEMP_NORMAL;
    }
}

Step 3: Import the Module and Analyse the Interface

Add temp_monitor.c to the TESSY project. TESSY performs automatic interface analysis:

  • Inputs identified: current_temp (int), rate_of_change (int)
  • Output identified: return value (TempStatus enum)
  • No global variables accessed
  • No called functions to stub

TESSY presents this interface in the test data editor, a tabular view with columns for each input and output variable.

Step 4: Design Test Cases

Open the test data editor for evaluate_temperature. Create test cases by adding rows to the table:

Test Casecurrent_temprate_of_changeExpected Return
TC1: Normal502TEMP_NORMAL
TC2: Warning, slow rise853TEMP_WARNING_STATE
TC3: Warning, fast rise858TEMP_CRITICAL_STATE
TC4: Critical temp1050TEMP_CRITICAL_STATE
TC5: Boundary - warning800TEMP_WARNING_STATE
TC6: Boundary - critical1000TEMP_CRITICAL_STATE
TC7: Just below warning7910TEMP_NORMAL

Each row is a test case, TESSY will set the input values, call the function, and compare the actual return value against the expected value.

For a more systematic approach, use the Classification Tree Editor: define equivalence classes for current_temp (below warning, warning zone, critical zone) and rate_of_change (low, medium, high), then generate test vectors from the combination matrix. The CTE ensures you cover boundary values and edge cases systematically.

Step 5: Execute Tests

Click the execute button (or press the keyboard shortcut). TESSY:

  1. Generates the test driver code (harness that calls evaluate_temperature with each test case’s inputs)
  2. Compiles the test driver + source module with your cross-compiler
  3. Executes the compiled test binary (on host simulator or on target via SEGGER J-Link)
  4. Captures results and compares actual outputs against expected values
  5. Measures code coverage

Execution takes seconds for a simple module. Results appear in the test data editor, green for passed test cases, red for failures.

Step 6: View Coverage Report

Open the coverage view. TESSY displays the source code with colour-coded annotations:

  • Green lines: statements and branches that were executed
  • Red lines: statements and branches that were not executed
  • Condition-level highlighting: for MC/DC, each atomic condition is highlighted to show whether it has been independently demonstrated to affect the decision outcome

For our example function, the seven test cases should achieve high MC/DC coverage. The compound condition (current_temp >= TEMP_CRITICAL || (current_temp >= TEMP_WARNING && rate_of_change > 5)) has three atomic conditions, and our test cases exercise each one independently.

If any conditions are red, TESSY shows which specific combinations are missing, add targeted test cases to close the gaps.

Step 7: Generate Reports

TESSY generates reports in HTML and PDF formats:

  • Test case report: all test cases with inputs, expected outputs, actual outputs, and pass/fail status
  • Coverage report: statement, branch, decision, and MC/DC coverage percentages with annotated source code
  • Requirements traceability: if requirements are linked (via ReqIF import), the report shows which requirements are verified by which test cases

These reports are suitable for inclusion in an ISO 26262 safety case or DO-178C certification package.

Next Steps

This tutorial covered the basic workflow on a simple module. For real project evaluation:

  1. Import your actual firmware module: a safety-critical function from your current project
  2. Configure your production compiler: test with the same toolchain you ship
  3. Try on-target execution: connect a SEGGER J-Link and run tests on your hardware
  4. Set up CI/CD: integrate TESSY into your Jenkins or GitLab pipeline for automated regression testing

Why Buy from GSAS

GSAS Micro Systems is the authorized Razorcat partner, providing TESSY evaluation licenses, onboarding training, and hands-on proof-of-concept support. Our engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR walk your team through the TESSY workflow on your actual codebase, not a contrived example, but your production firmware compiled with your toolchain on your target hardware.

Request a TESSY evaluation license →

Interested in Razorcat tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

Embedded engineering bench in India, illustrating the hardware a developer can act on today, supported by GSAS
Technical Guides Arm

Arm's Agentic AI Push: What Indian Embedded Teams Can Actually Use Today

Arm has set out its platform strategy for the agentic era, putting inference everywhere it has compute. Indian embedded teams can start on that direction this quarter with the Cortex-M toolchain they already own: Helium, CMSIS-NN, Ethos-U and Vela, on boards you can order today.

13 Sept 2026 · 7 min read
Side by side comparison of a 10BASE-T1S multidrop mixing segment, one balanced pair with four nodes on short stubs and a termination at each end, against a point to point star of four separate links into switch ports, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

10BASE-T1S and PLCA: Multidrop Ethernet Explained

10BASE-T1S is the one member of the T1 single-pair Ethernet family that keeps a shared medium, and PLCA is the reconciliation sublayer that stops the nodes on it from colliding. This article covers what IEEE 802.3cg standardises, how the beacon and transmit opportunities schedule a cycle, the node count and segment length figures the OPEN Alliance interoperability test suite works to, and the failure modes that put a segment quietly back into contention while every link still looks up. Written by the GSAS Micro Systems engineering team in India for teams bringing up multidrop segments on the bench.

29 Aug 2026 · 12 min read
The bench to harness adapter path drawn left to right: the ECU connector, a test lead, a media converter or pluggable T1 module, RJ45, and the host, showing where each connector family sits between the device under test and the laptop, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Automotive Ethernet Connectors: H-MTD, MATEnet, MQS

An ECU arrives on the bench with a connector nobody has a mate for, and the day is gone. Search the family names and you get connector product pages that describe their own part and stop there. This article puts the families side by side in one table using only what their public pages state, then makes the point those pages leave out: the IEEE link segment definition, not the connector, is what sets reach and loss limits, and shielding is a channel decision rather than a preference. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 12 min read