Functionize supports long-running test cases within the limits below. This page covers those limits, why long runs can slow down, and how to keep them reliable.
Test Length
A single test case can run up to 1,000 steps.
That's the supported maximum, but we recommend keeping each test case focused on a single feature. As a rule of thumb, aim for no more than 100 steps. Split larger flows into smaller test cases grouped in an orchestration. They're easier to maintain and give you faster feedback when something changes in your application.
Test Duration
A single test case can run for up to 3 hours 30 minutes.
When a test case reaches that limit, execution stops on the next step or at the end of the current one. The run then continues normally through result collection, so reports, screenshots, and video are all produced and uploaded as usual. The run is marked as finished, the reason is shown next to the result, and every step that ran is included.
Why is my test slow?
Page complexity and repeated interactions
Memory use during a run depends on how complex the pages under test are and how many interactions the test case performs on a single page.
The same is true for speed. As a page grows, each interaction takes longer because the browser has more content to process. So if a test case slows down as it goes, it's usually the page that has grown, not the test case that has become too long.
That's worth knowing when a run is slow or hits memory errors, because it tells you where to look.
Browser memory-pressure warnings
Functionize monitors the size of the page under test as a run progresses and records a warning on any step where the number of DOM nodes grows sharply. The run continues; the warning does not stop execution.
These warnings point to where content is accumulating in the browser tab, which makes them a good starting point for investigating the application under test. Review them even on runs that passed, since they're the earliest signal of this behavior.
High memory usage on the test machine
If system memory on the test machine passes 95%, the current step reports "System memory usage dangerously high." If a run doesn't complete, or you see problems during execution, try the steps below.
What to do about it
Ease the load within a test case
- Navigate directly. Go straight to the screen the test case needs instead of driving through a large intermediate page.
- Close what you're done with. Close panels, dialogs, and data grids once the test case no longer needs them, so the browser can reclaim the memory.
- Refresh the page periodically. On flows with many interactions against the same page, a page refresh at a suitable point clears accumulated content from the tab. Choose a point where the test case doesn't depend on unsaved in-page state.
- Verify individual elements. Validating elements one at a time, rather than large sections, reduces how much of the page has to be processed.
Design tests that stay fast
- Split long flows into an orchestration. Break them into smaller test cases grouped in an orchestration. Each run performs fewer interactions on one page, so fewer DOM elements accumulate before it ends. This is the single most effective change.
- Split at natural boundaries such as login, data setup, and verification. Each test case stays focused and is simple to re-run.
- Disable captures you don't use. Console and network capture are independent settings. Turning off one you never read reduces memory use.
- Track only the URLs you need to verify. Response bodies are captured for tracked URLs only.
- Check your application for memory leaks. If a page accumulates memory as it's used, that affects automated runs the same way it affects manual use. Repeat the test case's interactions in your browser's developer tools to see whether the growth comes from the application itself.
When a run doesn't finish
A run can occasionally end before completing for reasons outside the test case itself. When this happens, the run reports why it stopped, and each reason is distinct: the browser ran out of memory, the test case reached its time limit, a test machine couldn't be provisioned in time, the browser didn't become ready, or the result couldn't be delivered.
The steps that ran are shown, along with the data collected up to that point, so you can see how far the test case got and what it was doing last.
Report any run that doesn't complete so we can look into it. Submit a request under Technical Support and include the reason shown on the run.
Live execution on long runs
The live view refreshes every few seconds while a test case runs, adding steps as they complete. On longer runs the step list grows, and the view takes longer to render as it does.
Live Debug sessions are given more time than unattended runs, since a paused session is expected to wait for input.
Current limitations
Resuming a run from where it stopped. A run that doesn't finish has to be re-run from the beginning. There's no checkpoint or resume capability today. This is one reason we recommend the orchestration approach above.
Reducing capture automatically under memory pressure. Memory pressure is recorded and reported, and a step fails if system memory becomes critical. But a run won't automatically reduce what it captures to keep going, and there's no mode that trades result detail for a higher chance of completing.
Guaranteed completion against very large pages. Memory use is largely a property of the application under test. We can't guarantee that a test case will complete against pages large enough to destabilize the browser on their own, at any test case length. Browser memory-pressure warnings are the signal that a test is approaching this point, and support can help review your options.
Getting help
If you've tried the steps above and the problem continues, or you're seeing memory-related results you'd like reviewed, submit a request under Technical Support. Include what you're seeing, the steps you've already tried, and the reason shown on the run if it didn't complete. That lets us investigate the specific case faster.