Blog

Almost every application eventually tests a nested piece of data: an API response, a JSON config file, a serialized object, module metadata. The data is a struct that contains an array that contains structs that contain more structs, and the thing you actually care about is one value buried at the bottom.

This post has two halves. First we look at BoxLang's Data Navigator, the language feature that makes nested data pleasant to work with. Then we look at the six TestBox 7.1 expectations built on top of it. If you have never used dataNavigate(), start at the top. If you already know it, skip to The six expectations.

Before exploring the 14 range matchers, let’s take a closer look at the BoxLang Range itself. Ranges go well beyond the familiar .. syntax, providing a powerful and flexible foundation for working with sequences and boundaries. Understanding how ranges work makes the matcher API much easier to use and reason about. If you are coming from a CFML background, then this will be brand new to you as ranges have never existed until Boxlang.

If you have ever tested that two collections contain "the same stuff, order doesn't matter," you already know the workaround: sort both arrays, compare them element by element, and hope nobody adds a duplicate. It works, but it isn't what you meant to write. You meant "these are the same set."

Reasoning-capable models have been usable in BoxLang AI for a while. params passes straight through to the provider body, so params: { thinking: { type: "enabled", budget_tokens: 10000 } } for Claude, or params: { reasoning_effort: "high" } for OpenAI, already reached the API. What never worked was reading the reasoning back. It was parsed out on arrival and silently dropped. In 3.4.0, that's fixed, and it's fixed the same way for every provider.

TestBox 7.1.0 is here, and it is the largest single expansion of our assertion and expectation library since TestBox was born.

You call writeDump() on an ORM entity or a very rich class graph . The browser locks up. Thirty seconds later you get a page with forty thousand rows on it, you scroll for a while, you give up, and you go edit your code to dump a sub-key instead. Or worse, you crash the server.

LLM applications face a class of attack traditional input validation was never built for: prompt injection. An attacker embeds instructions in user input, a retrieved document, a web page your tool fetched, or an MCP result, trying to override your system prompt, exfiltrate data, or hijack a tool call. BoxLang AI 3.4.0 ships four layered, configurable defenses against exactly this, plus one more that's on unconditionally.

Everyone knows the datasource password should not be sitting in plain text in a config file. Everyone has also, at some point, shipped exactly that, because the alternative was a pile of environment variable plumbing that nobody wanted to build on a deadline. x

Here's a bug that's easy to miss until it bites someone in production: an agent turn asks for two tool calls at once, both need human approval, and only the first one actually suspends. The second one gets silently skipped. Not rejected, not queued, just gone. That's what happened before 3.4.0, and it's fixed now with batched tool-call approvals.

HumanInTheLoopMiddleware used to do everything itself: decide which tool calls needed approval, present the request, and wait for a decision. In 3.4.0, that logic has been pulled apart into a real subsystem, and the piece developers will feel the most is that a human's "always allow this" now actually means always.