Zeek unit testing with BTest: what changes for package authors?

TL;DR: Zeek package authors can use BTest and assert statements to test auxiliary functions, floating-point comparisons, and vector equality when PCAP-based testing is impractical, according to Corelight. The pattern matters because deterministic script-level tests reduce blind spots in security tooling before event-driven packages reach production.

Editorial analysis by NHI Mgmt Group, based on content published by Corelight: “The Cure for Exceptional Zeek Package Testing (Part 1)”.

Key questions

Q: How should teams test Zeek packages when they cannot use a PCAP?

A: Use manual event generation for narrow, deterministic paths and event traces when you need realistic replay.

Q: Why do floating-point checks fail in security analytics tests?

A: Floating-point checks fail because computed values are often approximate, so exact equality can break even when the result is correct.

Q: What should security teams do when a test returns structured output instead of a single value?

A: They should validate each element of the structure and then reduce the result to a single pass or fail decision.

Practitioner guidance

• Build assertion-based Zeek tests Place deterministic checks in zeek_init and use BTest to execute them on every package change so logic regressions fail immediately.
• Use tolerance helpers for numeric logic Wrap floating-point comparisons in a helper that accepts small precision variance, especially for scoring, distance, and threshold calculations.
• Validate structured outputs element by element Reduce vector or list comparisons to a single pass or fail outcome only after every element has been checked for equality.

Bottom line: Zeek package testing becomes much more reliable when teams replace manual inspection with assertion-driven checks that run automatically.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →