Skip to main content
TESSY vs VectorCAST: Stub Generation, Test Data, Coverage Depth, and AUTOSAR Workflows Compared, featured image

TESSY vs VectorCAST: Stub Generation, Test Data, Coverage Depth, and AUTOSAR Workflows Compared

GSAS Engineering · · 6 min read

TESSY vs VectorCAST: Stub Generation, Test Data, Coverage, and AUTOSAR

Choosing between Razorcat TESSY and Vector VectorCAST is one of the more consequential tooling decisions an Indian embedded team makes. Both tools automate embedded C/C++ unit testing with safety qualification. Both support MC/DC coverage. Both integrate into CI/CD pipelines. The choice often comes down to five factors: stub generation quality, test data editing workflow, coverage depth, AUTOSAR integration approach, and ecosystem fit.

This article examines each factor in technical detail to help teams make an informed decision.

Automatic Stub Generation

When testing a function in isolation, every function it calls must be replaced with a controllable stub. The quality of automatic stub generation directly affects how much manual effort engineers spend on test setup.

TESSY performs automatic interface analysis, parsing the function under test to identify all called functions, accessed global variables, and pointer-based dependencies. TESSY then generates stub skeletons for each dependency. Engineers define return values, output parameter behaviour, and call-sequence expectations per test case through TESSY’s graphical test data editor. Stubs can be configured to return different values on successive calls, enabling state machine and error injection testing.

VectorCAST also generates stubs automatically. Its Stub-by-Stub editor allows per-stub configuration, and VectorCAST supports stub callback functions for complex behaviours. VectorCAST’s auto-generation uses its basis path algorithm to create initial test cases that exercise the stubbed call paths.

In practice, both tools handle straightforward function stubs well. TESSY’s graphical interface for per-test-case stub configuration is more visual, engineers see the entire input/output/stub matrix for a test case in one view. VectorCAST’s approach is more code-oriented, which some engineers prefer. The choice here depends on team workflow preference.

Test Data Editor

How engineers specify test inputs and expected outputs significantly affects productivity when building hundreds of test cases for a safety-critical module.

TESSY’s test data editor presents a tabular view: rows are test cases, columns are input variables, output variables, global states, and stub configurations. Engineers can see all test cases for a function simultaneously and edit values inline. The Classification Tree Editor (CTE) sits above this, engineers define equivalence classes and boundary values graphically, and TESSY populates the test data table from the combination matrix.

VectorCAST’s test editor uses a tree-based interface where each test case is expanded to show inputs and expected values. Test cases can be duplicated and modified. VectorCAST also provides a compound testing mode for integration-level test sequences.

For large test suites (50+ test cases per function, common in ASIL D modules with complex boolean expressions), TESSY’s tabular view provides better overview and faster editing. VectorCAST’s tree-based approach works well for smaller test suites where each case needs detailed inspection.

Coverage Depth

TESSY measures statement, branch, decision, MC/DC, and MCC (Multiple Condition Coverage). MCC evaluates all possible combinations of atomic conditions within a decision, providing exhaustive coverage evidence for complex conditionals. While no current standard mandates MCC, it is useful for high-criticality functions where safety assessors want maximum confidence.

VectorCAST measures statement, branch, MC/DC, function, and call coverage. Function and call coverage metrics are useful at the integration level to verify that all functions are exercised and all call paths are tested.

Both tools satisfy ISO 26262 Part 6 structural coverage requirements for all ASIL levels. The difference is at the margins: TESSY goes deeper into condition combination analysis, while VectorCAST provides broader integration-level metrics.

CI/CD Pipeline Integration

TESSY provides a command-line interface for batch test execution. A typical CI pipeline step invokes TESSY to run all test suites, generate coverage reports, and return an exit code based on coverage thresholds. Reports in HTML and PDF can be archived as build artifacts. TESSY integrates with Jenkins, GitLab CI, Azure DevOps, and GitHub Actions through standard command-line invocation.

VectorCAST offers a dedicated CI module (VectorCAST/CI) with plugins for Jenkins and Azure DevOps. A web-based analytics dashboard tracks coverage trends across projects and teams. VectorCAST also supports change-based testing, re-running only tests affected by code changes, which can reduce CI execution time for large codebases.

For Indian teams running CI on cloud infrastructure (common for Bengaluru and Hyderabad automotive Tier-1 suppliers), TESSY’s lean command-line approach requires fewer infrastructure dependencies. VectorCAST’s dashboard is more useful for organizations with multiple projects and centralized quality management.

AUTOSAR SWC Testing

VectorCAST integrates deeply with the Vector AUTOSAR ecosystem, DaVinci Configurator, CANoe, and vTESTstudio. For teams that already use Vector tools for AUTOSAR configuration and communication testing, VectorCAST provides a cohesive workflow where unit test results feed into system-level test campaigns.

TESSY tests AUTOSAR SWCs at the C source level, independently of the AUTOSAR configuration tool. From TESSY Version 6 onward the RTE is provided for an SWC automatically from the ARXML model description file rather than being stubbed by hand, per the TESSY V6 New Features document, whose feature compilation Razorcat provided. Because the input is the model itself, TESSY works with any AUTOSAR stack, Elektrobit tresos, ETAS ISOLAR, or Vector DaVinci, without vendor coupling. The V6 workflow is walked step by step in our complete AUTOSAR verification chain guide.

For Indian teams using non-Vector AUTOSAR stacks (Elektrobit tresos on AURIX is widespread among Pune and Chennai Tier-1 suppliers serving European OEMs), TESSY’s vendor-neutral approach is the better architectural fit. For teams committed to the full Vector toolchain, VectorCAST’s deeper integration provides workflow convenience.

Ecosystem Fit

TESSY integrates with the tools that GSAS supplies across India: Arm Keil MDK for Cortex-M compilation, SEGGER J-Link for on-target debug and test execution, and Perforce Helix QAC for MISRA static analysis. This creates a complete ISO 26262 verification stack sourced and supported locally.

VectorCAST fits naturally into Vector’s own ecosystem. For teams that use CANoe, CANape, and DaVinci, adding VectorCAST keeps everything under one vendor umbrella.

Why Buy from GSAS

GSAS Micro Systems is the authorized Razorcat partner, providing TESSY licensing with INR invoicing, evaluation support, onboarding training, and CI/CD integration consulting. Our engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR have supported teams through TESSY evaluations alongside VectorCAST, running proof-of-concept tests on real project code so teams can compare results objectively. If you are evaluating embedded unit testing tools, we can set up a side-by-side comparison on your codebase.

Request a TESSY evaluation →

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 verification and unit test workflow, illustrating the economics of finding defects early, supported by GSAS Micro Systems in India
Technical Guides

Verification Economics: What a Late Defect Actually Costs, and What the Evidence Really Says

Finding a defect in month 2 instead of month 14 is a budget decision before it is a quality decision. This sets out what the published evidence supports, what it does not, including the 100x multiplier that traces back to a course handout rather than a study, and how an Indian embedded team builds the case on its own numbers.

21 Sept 2026 · 14 min read
Embedded development bench, illustrating the hardware debug loop an AI agent can now drive, supported in India by GSAS
J-Link SEGGER

An AI Agent That Drives the Debugger: SEGGER and Embedder Connect J-Link to the Loop

SEGGER has given an AI coding agent direct control of J-Link and J-Trace: flash, breakpoints, memory inspection and live RTT on real silicon. The loop only works if the probe can read target RAM while the core runs, and GSAS field engineers know exactly where that breaks first.

13 Sept 2026 · 6 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