v3.1.1

Fixes

• I broke backward compatibility with our old unitt.toml on v3.1.0 config file.
• I forgot to update the example section on documentation, where the output shows .unitt/* for each test-file. I've fixed this output on v3.1.0, but I forgot to update the documentation. This is an important feature because you can Ctrl + LMB on the file name on your favorite code editor, and this will open that file in a new editor tab.

Full Changelog: v3.1.0...v3.1.1

v3.1.0

What have changed

User view

Standalone files support

Now, you can run your tests directly without calling unitt:

import {unitt}!

; Your tests here

if standalone?
    unitt\report 'minimal ; or 'full

This will both, display the tests in your terminal and exit with appropriate exit code. You can pass .keep if you wish your script running after printing.

If you're interested on add custom support for unitt, you can also debug the final report, by verifying unitt\results.

Developer view

• The internals are easier to deal with. I've refactored both, the back and the frontend of the project into smaller and testable objects.
• Enhanced code-coverage: this tests unitt under different situations, including custom config, cli config overriding and internal API tests.

This ensures unitt will be solid for the future. Less error-prone, easier to change and adapt.

Pull Requests

• Fix plurals in summaries by @drkameleon in #56
• Internal refactoring (front-end) by @RickBarretto in #57
• Add support for standalone test-files by @RickBarretto in #58
• Simplify unitt calls in a standalone context by @drkameleon in #59
• Enhance standalone by @RickBarretto in #60
• Increase code coverage by @RickBarretto in #61

Full Changelog: v3.0.2...v3.1.0-pr1

v3.0.2

What's Changed

• Expand test matrix & clean up workflow by @drkameleon in #55

Full Changelog: v3.0.1...v3.0.2

v3.0.1

What's Changed

Now we use config.art instead of unitt.toml for the config file.

• Update typo in readme.md by @BNAndras in #47
• Change configuration file by @drkameleon in #51
• Add test workflow by @drkameleon in #52
• Use new setup action by @drkameleon in #53
• Keep retro-compatibility with our old unitt.toml config file by @RickBarretto in #54

New Contributors

• @BNAndras made their first contribution in #47

Full Changelog: v3.0.0...v3.0.1

Unitt v3

Unitt v3 Announcement

I'm happy to announce the 3rd version with a completely different architecture, without changing the API that much.
Initially written in Rust, I rewrote in Arturo again to support out-of-box pkgr's scripts, that can be found at ~/.arturo/packages/bin/.

Rust helped me a lot to create and refine this new architecture, where the tests outputs to .unitt folder and then read and displayed on terminal, but to avoid distributions issues I decided to just stick to pure Arturo.

Very thanks to @drkameleon and @BNAndras that helped me a lot to improve unitt.

I've updated Arturo's codebase to use this version, and everything is working fine ¹ with no code change.
Running a total of 1268 assertions and no failures ².

• New Architecture: A new architecture was introduced, opposed to the older ones. Now, each test module are isolated and does not pollutes the stdout as the 1st version did.
• Out-of-box runner: No need to setup manually. Just call unitt, thanks to @drkameleon that added the feature of running scripts via Arturo package manager.
• Flexible API: Keeps supporting both styles, XUnit and RSpec.
• Removed Unnecessary Attributes: .prop and .static removed.
• Dropped fatal: The fatal flag is gone; Code will always stop when uncaught exception is raised

What's Changed

• Move to v3 by @RickBarretto in #43
• Add more commands by @RickBarretto in #44
• Arturo's v3 by @RickBarretto in #45

Full Changelog: v2.0.1...v3.0.0

1. arturo-lang/arturo#1988 ↩

2. https://github.com/arturo-lang/arturo/actions/runs/16554762099/job/46814652861?pr=1988#step:4:24 ↩

Unitt v3 - Pre-Release 1

v3.0.0-pre1

Correctly nest sub-header

Unitt v3 - Pre 0

This pre-release was made for debugging purposes. Please, don't use it.

What's Changed

• Move to v3 by @RickBarretto in #43
• Add more commands by @RickBarretto in #44

Full Changelog: v2.0.1...v3.0.0-pre0

Unitt v2

What is new?

New Runner System

On our first version, this was introduced the concept of runner/tests, there isn't it anymore. The runner now exists as the test file I've put on Readme, just copy & paste it 😉.

This will work simple like this:

./test test/*test.art

Or this:

./test

New API

As the older one was not removed from unitt, the documentation and examples focuses more on the new API inspired by RSpec.
You can see them on the docs as well, in example.art.

The older one was kept for compatibility reasons, be free to use it if you want. But our new vision is actually based on RSpec.

import {unitt}!

unix?: true

describe "binary appending" [
    it "should operate integers" [
        b: to :binary 0
        expects.be: 'equal? @[as.binary 2 append b 1]
        expects.be: 'equal? @[as.binary 1 b ++ 1]
    ]

    it "should return a binary" [
        b: to :binary 0
        expects.be: 'binary? @[append b 1]
        expects.be: 'binary? @[b ++ 1]
    ]
]

test.skip: unix? "split should deal with windows's paths" [
    expects.be: 'equal? @[
        ["." "splited" "path"]
        split.path ".\\splited\\path"
    ]
]

test "split should deal with unix path" [
    expects.be: 'equal? @[
        ["." "splited" "path"] 
        split.path "./splited/path"
    ]
]

No more useless variables anymore

As everyone knows, due to Arturo's nature, I've been using the expect/actual variables pattern to get clear results when running tests. The reason for this is that evaluating the whole expression directly would simply return true or false, which isn't very informative when reading test results. To address this, I've developed a custom function that selectively evaluates parts of the expression. For instance, :words are evaluated to display their variable values, providing clearer insights into the test outcomes. Our new API simply fix this issue.

Before:

test "appending [1 2] and 3 should be [1 2 3]" [
  assert -> equal? @1..3 append @1..2 3
]

This will display:

✅ - assert that appending [1 2] and 3 should return [1 2 3]
     assertion: equal? @ 1 .. 3 append @ 1 .. 2 3

But, I want to see the generated :blocks instead of this raw expression, so let's use the actual/expected pattern:

test "appending [1 2] and 3 should be [1 2 3]" [
  expected: @1..3
  actual: append @1..2 3
  assert -> equal? expected actual
]

And boom, we have what we wanted:

✅ - assert that appending [1 2] and 3 should return [1 2 3]
     assertion: equal? [1 2 3] [1 2 3]

However, take a look at the above code. It's unreasonably ugly and requires writing more code to follow a pattern, so let's replace it. Patterns are essentially undiscovered features.

Now:

it "should be [1 2 3] when append [1 2] and 3" [
  expects.be: 'equal? @[@1..3, append @1..2 3]
]

Displays:

✅ - assert that should be [1 2 3] when append [1 2] and 3
     ✅: equal? [1 2 3] [1 2 3]

Simple, no? 😉

What's Changed

• Re-structure by @RickBarretto in #32
• Initial implementation of CLI Runner by @RickBarretto in #33
• Implement: assert.with feature by @RickBarretto in #36
• Implementing RSpec-ish API by @RickBarretto in #37
• Update documentation by @RickBarretto in #38
• Road to v2 by @RickBarretto in #39

Full Changelog: v1.1.2...v2.0.1

v1.1.2

Fix

• Returning Error code 0 when fail.

Full Changelog: v1.0.0...v1.1.2

First Official Release

What's Changed

• Changes: decouple runner and finder by @RickBarretto in #21

If you want to get a full changelog, have a look on unitt/releases.

At a Glance

Here is the feel and look of the current implementation:

---

Full Changelog: v0.2.0...v1.0.0