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

Master and slave roles on a 100BASE-T1 link: the master PHY times its transmitter from a local clock, the slave recovers the clock from the received signal, with the both-master and both-slave misconfigurations that leave the link down, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

100BASE-T1 Link Won't Come Up: A Vendor-Neutral Checklist

A 100BASE-T1 link that will not come up is almost never a mystery, but the answers on the web are written per silicon vendor and do not transfer. This is the ordered bring-up checklist that holds regardless of which PHY, switch or SoC you have: physical layer first, then the PHY over MDIO, then the master and slave pairing, then the causes of a link that comes up and drops. The standards and tooling claims trace to IEEE 802.3 task force records, the Linux ethtool and kernel documentation or published test material. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 14 min read
Storage sizing ladder for automotive data logging: four rungs stepping from an aggregate link rate of 1 Gbit/s to 125 MB per second, then 450 GB per hour, then 3.6 TB per eight-hour shift, then 18 TB per five-day week, in decimal units, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

Automotive Data Loggers: Capture Without Loss

Search for an automotive data logger and the results split into cheap OBD dongles at one end and enterprise ADAS recorders at the other, with nothing in between explaining the engineering that decides whether you lose frames. This is the loss budget end to end: mirror oversubscription upstream of the logger, encapsulation overhead on the capture path, sustained write rate against burst rate, rotation stalls, and storage arithmetic worked in full so you can redo it with your own numbers instead of trusting ours. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 13 min read
Ladder chart of the T1 single-pair Ethernet family by data rate: 10BASE-T1S (802.3cg), 100BASE-T1 (802.3bw), 1000BASE-T1 (802.3bp), 2.5/5/10GBASE-T1 (802.3ch) and 25GBASE-T1 (802.3cy), one balanced pair across five IEEE standards, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

The T1 Family Explained: 10BASE-T1S to Multi-Gig 802.3ch

The T1 family is the set of single-pair Ethernet physical layers used in vehicles, and every member is documented separately inside a different datasheet. This guide puts all of them in one table with rate, symbol rate, line code, specified reach and cabling traced to public IEEE task force documents, then answers the two questions that keep coming back: why 100BASE-T1 has no auto-negotiation, and why one end has to be master. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 13 min read