Statistical Mean-Reversion Engine [SMRE]## Statistical Mean-Reversion Engine (SMRE)
SMRE is an open-source mean-reversion indicator that combines a rigorous statistical core with up to eight optional confirmation layers, designed primarily for index-futures trading on intraday timeframes (1-minute through 1-hour).
### What it does
For every bar, SMRE fits an Ornstein-Uhlenbeck (OU) process to the recent price series via linear regression on lag-1 prices, yielding four outputs:
- **μ (the mean)** — the equilibrium price the series is reverting to
- **θ (mean-reversion speed)** — how strongly the series pulls back to μ
- **HL (half-life)** — how many bars it takes to revert halfway
- **σ_eq (stationary residual variance)** — used to z-score the current price
The current price's z-score against μ (the "OU Z") is the primary signal. When |OU Z| exceeds a configurable threshold, a mean-reversion entry is considered — but only after the script also confirms that the recent price series is genuinely stationary using three orthogonal statistical tests:
- **Hurst exponent** must be below 0.55 (i.e., the series is not persistently trending)
- **Augmented Dickey-Fuller** t-statistic must be below -2.86 (rejects unit root)
- **Variance Ratio** test at q=4 must be below 1.0 (variance grows sub-linearly with horizon)
If all four conditions pass, the L1 (statistical core) signal fires.
### Why the multi-layer structure (mashup justification)
A single OU-based mean-reversion signal works well in stationary regimes but degrades in trending or volatile conditions. SMRE addresses this by validating each potential entry through up to eight orthogonal confirmation channels, each measuring something the others do not:
- **L2 — Volatility Regime (6-state):** Classifies market state via VIX, ADX, and realized volatility. Suppresses signals during high-trend conditions (regime 6, "Spike") where mean-reversion historically fails.
- **L3 — Spot-Futures Basis (Kalman filter):** Tracks the deviation between actual and theoretical futures pricing. Statistically significant basis dislocations often resolve via mean-reversion.
- **L4 — Options Surface:** Computes ATM implied volatility from straddle pricing and a skew z-score from OTM put/call ratio. Optional; requires user to provide option symbols.
- **L5 — Microstructure:** Blends rolling VWAP and session-anchored VWAP z-scores with VPIN (a volume-clock toxicity proxy) and order-flow imbalance. Captures flow-based exhaustion.
- **L6 — Gamma Walls (GEX) OR Put-Call Ratio:** Two mutually exclusive options. GEX requires OI symbols at five strikes; PCR requires a single broker-published PCR feed. Both detect option-driven price magnets.
- **L7 — Dispersion:** Rolling correlation of index returns with its top 5 constituent stocks' returns. High dispersion (low correlation) penalizes signals; high cohesion boosts them.
- **L7b — Residual Dispersion:** Idiosyncratic residual z-scores (β-adjusted) per constituent. If 3 of 5 stocks show same-sign extreme residuals, the index is detached from constituents — strong mean-reversion candidate.
- **L9 — Cross-Asset Stress:** Sigma-normalized stress across USD/INR, DXY, and crude oil. Penalizes signals during cross-asset hedging cascades.
Each layer outputs a {direction, strength} pair. The Layer 8 fusion engine combines these via a weighted composite score (default weights: L1=0.28, L5=0.22, L3=0.18, L4=0.12, L6/L7b=0.10), then applies a regime multiplier (L2 × L7 × VRP × cross-asset × expiry), clamped to to prevent extreme compounding.
If the absolute composite score crosses one of three thresholds (0.25 / 0.40 / 0.45 by default), a signal is fired at Scalp / Swing / Session horizon respectively. A TCA cost filter then validates that the expected move (distance to μ) exceeds estimated round-trip transaction cost; otherwise the signal is suppressed.
### Originality
The author is not aware of any other public Pine script that implements the full OU-fit chain (mean, mean-reversion speed, half-life, stationary variance) together with all three stationarity tests (Hurst, ADF, Variance Ratio) directly in Pine v6 — every step is computed natively, no external library calls. Additionally, the session-anchored VWAP with running volume-weighted sigma bands, the rolling-beta residual dispersion across multiple constituents, and the Kalman-filtered futures-basis residual are original Pine implementations. The signal telemetry module (a 200-signal FIFO ring buffer with horizon × composite-magnitude bucket attribution) is also an original diagnostic tool.
### How to use
1. **Apply to an index futures chart.** Defaults are pre-configured for NSE NIFTY1! futures, but inputs allow any index — change the VIX symbol, spot/futures symbols, constituent symbols, and currency pairs.
2. **Read the compact dashboard.** It's a single 9-row table (default position: middle-right) showing only what you need to evaluate a setup:
| Row | What it shows | What it means |
|---|---|---|
| Title | Profile + OU window in use | Confirms which calibration is active |
| OU Z-Score | Z-score with half-life (HL) | How extended price is + how long mean-reversion typically takes |
| Stat Validity | H / ADF / VR pass-fail | Whether the recent series is actually stationary (all 3 must pass) |
| Regime | Volatility state + VIX value | Whether market conditions favor mean-reversion |
| Composite | Fused score × regime multiplier | The unified signal strength |
| Confluence | Layers agreeing (out of 6) | How many orthogonal signals support the direction |
| TCA Edge | Expected move in bps + PASS/FAIL | Whether the trade clears transaction costs |
| E / SL / TP | Entry, Stop, Target + Risk:Reward | The trade levels if a signal fires |
| **DECISION** | Direction · Horizon · Side | The actionable output (green=long, red=short, gray=neutral) |
3. **Trade levels and markers.** When a signal fires, entry/stop/target lines auto-plot on the chart. Stop is ATR-based (default 1.2× ATR); target is min(OU mean μ, entry + 2× ATR). Triangle markers plot below (long) or above (short) the bar — small for Scalp, medium for Swing, large for Session.
4. **Optional diagnostic.** A separate Signal Telemetry table (disabled by default; enable via the "Show Telemetry Dashboard" input) tracks the last 200 signals' outcomes (win = price touched μ, loss = stop hit, expired = timeout) and reports hit rate by horizon × composite-magnitude bucket. This is a backward-looking diagnostic, not a backtest.
### Recommended chart and timeframe
This indicator was developed and parameter-tested primarily on NIFTY1! futures. The OU window auto-mapping (1m→32, 2m→20, 5m→12, 15m→32, 30m→20, 1h→24) was selected empirically through parameter sweeps. Users on other instruments should expect to tune the OU window manually or accept the auto-mapped default as a starting point.
The indicator works on any timeframe between 1 minute and daily, though intraday timeframes (1m through 1h) are where the multi-layer confluence adds the most value.
### Important notes
- This is an **indicator**, not a strategy — no backtest equity curve is produced. The telemetry table is a descriptive measure of recent signal outcomes only.
- Many layers are **optional**. If you don't have symbols for options OI, just leave those inputs blank; the script will redistribute composite weight naturally across the active layers.
- Signals can fluctuate intra-bar before bar close, especially in real-time mode. For consistent behavior, evaluate signals on closed bars only.
- The default constituents (top-5 NIFTY weights) need to be changed in the L7 inputs to use this on a different index.
### Disclaimer
This indicator is published for educational and research purposes only. It is not financial advice, not an investment recommendation, and not a solicitation to trade. Past behavior of signals does not guarantee future results. Trading futures, options, and equities carries substantial risk of loss. You are solely responsible for your trading decisions. The author makes no representations about the accuracy, completeness, or suitability of this indicator for any particular purpose. Use at your own risk, and always consult a qualified financial professional before trading.
Indicator
Indicator
Michael LipsiusTitle: Michael Multi-Timeframe Trend Dashboard (HTF Bias & LTF Execution)
Description:
Overview This indicator is a specialized Top-Down Analysis tool designed to assist traders in identifying the dominant market direction across multiple timeframes instantly. Built around the principles of Michael's Trading Strategy and institutional trend following, this dashboard eliminates the noise and provides a clear, color-coded directional bias (Prognosis) for both High Time Frame (HTF) structure and Low Time Frame (LTF) momentum.
Core Functionality The dashboard generates a real-time matrix displayed directly on the chart, analyzing price action relative to the 50-period Exponential Moving Average (EMA). This specific metric is chosen to filter out minor fluctuations and reveal the true institutional flow of money.
1. High Time Frame (HTF) Prognosis – The "Compass" The indicator monitors the Daily (D1) and 4-Hour (H4) timeframes to establish the macro trend.
Bullish 🟢: Price is holding above the 50 EMA. This indicates that Smart Money is accumulating, and traders should focus primarily on Long setups.
Bearish 🔴: Price is trading below the 50 EMA. This suggests institutional distribution, meaning Short setups have a higher probability of success.
Purpose: The HTF modules act as your safety filter. By respecting the D1/H4 signals, you avoid trading against the major trend, significantly reducing the risk of being stopped out by macro flows.
2. Low Time Frame (LTF) Execution – The "Trigger" Simultaneously, the indicator analyzes the 1-Hour (H1) and 15-Minute (M15) timeframes.
These timeframes are crucial for timing entries and managing intraday volatility.
Conflict Warning: If the HTF is Bullish (Green) but the LTF is Bearish (Red), the market is likely in a pullback phase. This warns the trader to wait for the LTF to realign with the HTF before entering.
How to Use This Tool This dashboard is designed to be the first step in your trading routine:
Check Confluence: Look for a "Full Green" or "Full Red" board. When D1, H4, and H1 align, the probability of a successful trade increases exponentially.
Identify Pullbacks: If D1/H4 are Green, but M15 is Red, do not sell. Instead, treat this as a discount phase and wait for the M15 to flip back to Green for a high-precision entry.
Risk Management: Use the HTF bias to determine your risk exposure. Trade with full risk only when HTF and LTF are aligned.
Settings & Customization
Table Position: Fully adjustable (Top Right, Bottom Right, etc.) to fit your workspace.
EMA Period: Default is set to 50 (Standard Michael Strategy), but can be adjusted to fit other strategies.
Visuals: Clean, non-intrusive design with clear color coding for instant readability.
Disclaimer This tool is for informational purposes only and serves as a trend-confirmation aid. It should be used in conjunction with price action analysis, key levels, and proper risk management. Indicator
tvunitLibrary "tvunit"
method assert(this, description, passed, bar)
Adds a test result to the test suite.
Namespace types: TestSuite
Parameters:
this (TestSuite) : The (TestSuite) instance.
description (string) : A description of the test.
passed (bool) : Whether the test passed or result.
bar (int) : The bar index at which the test was run.
Returns: Whether the assertion passed or result.
method assertWindow(this, runTests, description, bars, passed, stopOnFirstFailure)
Adds a test result to the test suite.
Namespace types: TestSuite
Parameters:
this (TestSuite) : The (TestSuite) instance.
runTests (bool) : Whether to run the tests.
description (string) : A description of the test.
bars (int) : The number of bars to test.
passed (bool) : A series of boolean values indicating whether each bar passed.
stopOnFirstFailure (bool) : Whether to stop on the first test failure.
Returns: Whether the assertion ran or not
method totalTests(this)
Returns the total number of tests in the test suite.
Namespace types: TestSuite
Parameters:
this (TestSuite) : The (TestSuite) instance.
Returns: The total number of tests.
method totalTests(this)
Returns the total number of tests in the test suite.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSuite) instance.
Returns: The total number of tests.
method passedTests(this)
Returns the total number of passed tests in the test suite.
Namespace types: TestSuite
Parameters:
this (TestSuite) : The (TestSuite) instance.
Returns: The total number of passed tests.
method passedTests(this)
Returns the total number of passed tests in the test suite.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSuite) instance.
Returns: The total number of passed tests.
method failedTests(this)
Returns the total number of result tests in the test suite.
Namespace types: TestSuite
Parameters:
this (TestSuite) : The (TestSuite) instance.
Returns: The total number of result tests.
method failedTests(this)
Returns the total number of result tests in the test suite.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSuite) instance.
Returns: The total number of result tests.
newTestSession()
Creates a new test session instance.
Returns: A new (TestSession) instance.
method addNewTestSuite(this, name, description)
Creates a new test suite instance.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSession) instance.
name (string) : The name of the test suite.
description (string) : (optional) A description of the test suite.
Returns: A new (TestSuite) instance.
method add(this, suite)
Creates a new test suite instance.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSession) instance.
suite (TestSuite) : The (TestSuite) instance to add.
Returns: The (TestSession) instance.
method totalSuites(this)
Returns the total number of sessions in the test session.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSession) instance.
Returns: The total number of sessions.
method report(this, show, showOnlyFailedTest)
Generates a report of the test session summary that is suitable for logging.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSession) instance.
show (bool) : Optional: Whether to show the report or not. default: true
showOnlyFailedTest (bool) : Optional: Whether to show only result tests or not. default: false
Returns: A formatted string report of the test suite summary.
method reportGui(this, show, pages, pageSize)
Generates a report of the test suite summary for the GUI.
Namespace types: TestSession
Parameters:
this (TestSession) : The (TestSession) instance.
show (bool) : Optional: Whether to show the report or not. default: true
pages (int) : Optional: The number of pages to show (columns). default: 4
pageSize (int) : Optional: The number of results to show per page (rows), excluding the header. default: 5
approxEqual(a, b, tolerance)
Checks if two floating-point numbers are approximately equal within a specified tolerance.
Parameters:
a (float) : The first floating-point number.
b (float) : The second floating-point number.
tolerance (float) : The tolerance within which the two numbers are considered equal. Default is 1e-6.
Returns: True if the numbers are approximately equal, false otherwise. If both are na, returns true.
TestResult
Fields:
description (series string)
passed (series bool)
bar (series int)
TestSuite
Fields:
isEnabled (series bool)
name (series string)
description (series string)
tests (array)
TestSession
Fields:
suites (array) Library
Library
Breakouts with Tests & Retests [LuxAlgo]The Breakouts Tests & Retests indicator highlights tests and retests of levels constructed from detected swing points. A swing area of interest switches colors when a breakout occurs.
Users can control the sensitivity of the swing point detection and the width of the swing areas.
🔶 USAGE
When a Swing point is detected, an area of interest is drawn, colored green for a bullish swing and red when bearish.
A test is confirmed when the opening price is situated in the area of interest, and the closing price is above or below the area, depending on whether it is a bullish or bearish swing. Tests are highlighted with a solid-colored triangle.
A breakout is confirmed when the price closes in the opposite position, below or above the area, in which case the area will switch colors.
If the opening price is located within the area and the closing price closes outside the area, in the same direction as the breakout, this is considered a retest . Retests are highlighted with a hollow-colored triangle.
Note that tests/retests do not act on wicks. The main factor is that the opening price is in the area of interest, while the closing price is outside.
🔹 Area Of Interest Width
The user can adjust the width of the swing areas. Changing the " Width " is a fast and easy way to find different areas of interest.
A higher "Multiple" setting would return a wider area, allowing price to develop within it for a longer period of time and potentially provide later test signals.
When a swing area is broken, a higher "Width" setting can make it more complicated for the price to break it again, allowing a swing area to remain valid for a longer period of time thus potentially providing more retest signals.
🔶 DETAILS
Generally, only one bullish/bearish pattern can be active at a time. This means that no more than 1 bullish or bearish area will be active.
The " Display " settings, however, can help control how areas of different types are displayed.
Bullish AND Bearish: Both, bullish and bearish patterns can be drawn at the same time
Bullish OR Bearish: Only 1 bullish or 1 bearish pattern is drawn at a time
Bullish: Only bullish patterns
Bearish: Only bearish patterns
🔹 Test/Retest Labels
The user can adjust the settings so only the latest test/retest label is shown or set a minimum number of bars until the next test/retest can be drawn.
🔹 Maximum Bars
Users can set a limit of bars for when there is no test/retest in that period; the area of interest won't be updated anymore and will be available and ready for the next Swing.
An option for pulling the area back to the last retest is included.
🔶 SETTINGS
Display: Determines which swing areas are displayed by the indicator. See the "DETAILS" section for more information
Multiple: Adjusts the width of the areas of interest
Maximum Bars: Limit of bars for when there is no test/retest
Display Test/Retest Labels: Show all labels or just the last test/retest label associated with a swing area
Minimum Bars: Minimum bars required for a subsequent test/retest label are allowed to be displayed
Set Back To Last Retest: When after "Maximum Bars" no test/retest is found, place the right side of the area at the last test/retest
🔹 Swings
Left: x amount of wicks on the left of a potential Swing need to be higher/lower for a Swing to be confirmed.
Right: The number of wicks on the right of a potential swing needs to be higher/lower for a Swing to be confirmed.
🔹 Style
Bullish: color for test period (before a breakout) / retest period (after a breakout)
Bearish: color for test period (before a breakout) / retest period (after a breakout)
Label Size
Indicator
PineUnitPineUnit by Guardian667
A comprehensive testing framework for Pine Script on PulseWire. Built with well-known testing paradigms like Assertions, Units and Suites. It offers the ability to log test results in PulseWire's built-in Pine Protocol view, as well as displaying them in a compact table directly on your chart, ensuring your scripts are both robust and reliable.
Unit testing Pine Script indicators, libraries, and strategies becomes seamless, ensuring the precision and dependability of your PulseWire scripts. Beyond standard function testing based on predefined input values, PineUnit supports series value testing. This means a test can run on every bar, taking into account its specific values. Moreover, you can specify the exact conditions under which a test should execute, allowing for series-based testing only on bars fitting a designated scenario.
Detailed Guide & Source Code
Quick Start
To get started swiftly with PineUnit, follow this minimalistic example.
import Guardian667/PineUnit/1 as PineUnit
var testSession = PineUnit.createTestSession()
var trueTest = testSession.createSimpleTest("True is always True")
trueTest.assertTrue(true)
testSession.report()
After running your script, you'll notice a table on your chart displaying the test results. For a detailed log output, you can also utilize the Pine Protocol view in PulseWire.
--------------------------------------------------------------
T E S T S
--------------------------------------------------------------
Running Default Unit
Tests run: 1, Failures: 0, Not executed: 0, Skipped: 0
To further illustrate, let's introduce a test that's destined to fail:
var bullTest = testSession.createSeriesTest("It's allways Bull Market")
bullTest.assertTrue(close > open, "Uhoh... it's not always bullish")
After executing, the test results will reflect this intentional discrepancy:
--------------------------------------------------------------
T E S T S
--------------------------------------------------------------
Running Default Unit
Tests run: 2, Failures: 1, Not executed: 0, Skipped: 0 <<< FAILURE! - in
It's allways Bull Market
Uhoh... it's not always bullish ==> expected: , but was
This shows how PineUnit efficiently captures and reports discrepancies in test expectations.
It's important to recognise the difference between `createSimpleTest()` and `createSeriesTest()`. In contrast to a simple test, a series-based test is executed on each bar, making assertions on series values.
License
This source code is subject to the terms of the Mozilla Public License 2.0 at mozilla.org
@ Guardian667
A Personal Note
As a software developer experienced in OO-based languages, diving into Pine Script is a unique journey. While many aspects of it are smooth and efficient, there are also notable gaps, particularly in the realm of testing. We've all been there: using `plotchar()` for debugging, trying to pinpoint those elusive issues in our scripts. I've come to appreciate the value of writing tests, which often obviates the need for such debugging. My hope is that this Testing Framework serves you well and saves you a significant amount of time, more that I invested into developing this "baby." Library
Indicator
Strategy
Indicator
MathSpecialFunctionsTestFunctionsLibrary "MathSpecialFunctionsTestFunctions"
Methods for test functions.
rosenbrock(input_x, input_y) Valley-shaped Rosenbrock function for 2 dimensions: (x,y) -> (1-x)^2 + 100*(y-x^2)^2.
Parameters:
input_x : float, common range within (-5.0, 10.0) or (-2.048, 2.048).
input_y : float, common range within (-5.0, 10.0) or (-2.048, 2.048).
Returns: float
rosenbrock_mdim(samples) Valley-shaped Rosenbrock function for 2 or more dimensions.
Parameters:
samples : float array, common range within (-5.0, 10.0) or (-2.048, 2.048).
Returns: float
himmelblau(input_x, input_y) Himmelblau, a multi-modal function: (x,y) -> (x^2+y-11)^2 + (x+y^2-7)^2
Parameters:
input_x : float, common range within (-6.0, 6.0 ).
input_y : float, common range within (-6.0, 6.0 ).
Returns: float
rastrigin(samples) Rastrigin, a highly multi-modal function with many local minima.
Parameters:
samples : float array, common range within (-5.12, 5.12 ).
Returns: float
drop_wave(input_x, input_y) Drop-Wave, a multi-modal and highly complex function with many local minima.
Parameters:
input_x : float, common range within (-5.12, 5.12 ).
input_y : float, common range within (-5.12, 5.12 ).
Returns: float
ackley(input_x) Ackley, a function with many local minima. It is nearly flat in outer regions but has a large hole at the center.
Parameters:
input_x : float array, common range within (-32.768, 32.768 ).
Returns: float
bohachevsky1(input_x, input_y) Bowl-shaped first Bohachevsky function.
Parameters:
input_x : float, common range within (-100.0, 100.0 ).
input_y : float, common range within (-100.0, 100.0 ).
Returns: float
matyas(input_x, input_y) Plate-shaped Matyas function.
Parameters:
input_x : float, common range within (-10.0, 10.0 ).
input_y : float, common range within (-10.0, 10.0 ).
Returns: float
six_hump_camel(input_x, input_y) Valley-shaped six-hump camel back function.
Parameters:
input_x : float, common range within (-3.0, 3.0 ).
input_y : float, common range within (-2.0, 2.0 ).
Returns: float Library
[UTILS] Unit Testing FrameworkTL;DR
This script doesn't provide any buy/sell signals.
This script won't make you profitable implicitly.
This script is intended for utility function testing, library testing, custom assertions.
It is free and open-source.
Introduction
About the idea: is not exclusive, programmers tend to use this method a lot and for a long time.
The point is to ensure that parts of a software, "units" (i.e modules, functions, procedures, class methods etc), work as they should, meet they design and behave as intended. That's why we use the term "Unit testing".
In PineScript we don't have a lot of entities mentioned above yet. What we have are functions. For example, a function that sums numbers should return a number, a particular sum. Or a professor wrote a function that calculates something or whatever. He and you want to be sure that the function works as expected and further code changes (refactoring) won't break its behaviour. What the professor needs to do is to write unit tests for his function/library of functions. And what you need to do is to check if the professor wrote tests or not.
No tests = No code
- Total test-driven development
Ok, it is not so serious, but very important in software development. And I created a tool for that.
I tried to follow the APIs of testing tools/libs/frameworks I worked or work with: Jasmine (Javascript), Mocha/Chai (Javascript), Jest (Javascript), RSpec (Ruby), unittest (Python), pytest (Python) and others. Got something workable but it would be much easier to implement (and it would look much better) if PineScript had a higher-order functions feature.
API
_describe(suiteName: string)
A function to declare a test suite. Each suite with tests may have 2 statuses:
✔️ Passed
❌ Failed
A suite is considered to be failed if at least one of the specs in it has failed.
_it(specName: string, actual: any, expected: any)
A function to run a test. Each test may have 3 statuses:
✔️ Passed
❌ Failed
⛔ Skipped
Some examples:
_it("is a falsey value", 1 != 2, true)
_it("is not a number", na(something), true)
_it("should sum two integers", _sum(1, 2), 1)
_it("arrays are equal", _isEqual(array.from(1, 2), array.from(1, 2)), true)
Remember that both the 'actual' and 'expected' arguments must be of the same type.
And a group of _it() functions must be preceded by a _describe() declaration (see in the code).
_test(specName: string, actual: any, expected: any)
An alias for _it . Does the same thing.
_xit(specName: string, actual: any, expected: any)
A function to skip a particular test for a while. Doesn't make any comparisons, but the test will appear in the results as skipped.
This feature is unstable and may be removed in the future releases.
_xtest(specName: string, actual: any, expected: any)
An alias for _xit . Does the same thing.
_isEqual(id_1: array, id_2: array)
A function to compare two arrays for equality. Both arrays must be of the same type.
This function doesn't take into account the order of elements in each array. So arrays like (1, 2, 3) and (3, 2, 1) will be equal.
_isStrictEqual(id_1: array, id_2: array)
A function to compare two arrays for equality. Both arrays must be of the same type.
This function is a stricter version of _isEqual because it takes into account the order of elements in each array. So arrays like (1, 2, 3) and (3, 2, 1) won't be equal.
Usage
To use this script to test your library you need to do the following steps:
1) Copy all the code you see between line #5 and #282 (Unit Testing Framework Core)
2) Place the copied code at the very beginning of your script (but below study())
3) Start to write suites and tests where your code ends. That's it.
NOTE
The current version is 0.0.1 which means that a lot of things may be changed on the way to 1.0.0 - the first stable version.
Indicator
Indicator
Indicator
Indicator
Indicator
Indicator
Indicator
Indicator
Indicator
Indicator
