$ ghrl | first
╭──────────────┬─────────────────────────────────────────────────────────╮
│ conclusion   │ failure                                                 │
│ displayTitle │ Add CLI completions                                     │
│ headBranch   │ clap-complete-16608                                     │
│ url          │ https://github.com/iesahin/xvc/actions/runs/13007688178 │
╰──────────────┴─────────────────────────────────────────────────────────╯

🐢 Although I turned off most of the watches, logs are still so large that it’s not possible to view them from the interface. Downloaded the log archive.

🦊 We can have different GitHub Actions steps for each test. Claude can help write such a repeating set of steps.

🐇 We can at least separate z_test_docs to see if integration tests or that fails.

🐢 We’ll have to add caching for test artifacts to upload them for coverage. I’m not sure we really need to add that complexity to the process just to avoid downloading the logs.

🐇 We can actually move all to Xvc. We need a GitHub Action to run an Xvc pipeline.

🐢 Eventually yes, we should move our testing to Xvc itself. Now, the logs show that there are differences in z_test_docs actually.

🐇 When I run the command below, it passes. We may have a different config in GitHub Actions.

$ XVC_TRYCMD_TESTS=storage,file,pipeline,core,start TRYCMD=overwrite rws cargo test --features test-ci -p xvc --test z_test_docs
test z_doc_tests ... ok
...
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 15.34s

🐢 We don’t have an XVC_TRYCMD_TESTS=storage,file,pipeline,core,start definition in GitHub Actions; let’s add it, bump the version, and try again.

$ cargo set-version "0.6.14-alpha.10"
   Upgrading xvc from 0.6.14-alpha.9 to 0.6.14-alpha.10
...

🦊 We could also update run-tests.zsh to get a quick response.

🐢 Yep, let’s do that as well.

🐇 Dev tests pass, but there are differences in the documents still. For some reason, the local run-tests.zsh doesn’t update xvc/book/src/ref/xvc-storage.md. It only has the help text as a reference, but it’s not updated with the aliases, and it breaks the CI. This is weird but a small issue. Fixed it manually.

$ ghrl | first 2
╭───┬────────────┬───────────────────┬────────────────────┬────────────────────╮
│ # │ conclusion │   displayTitle    │     headBranch     │        url         │
├───┼────────────┼───────────────────┼────────────────────┼────────────────────┤
│ 0 │            │ Add CLI           │ clap-complete-1660 │ https://github.com │
│   │            │ completions       │ 8                  │ /iesahin/xvc/actio │
│   │            │                   │                    │ ns/runs/1302770108 │
│   │            │                   │                    │ 2                  │
│ 1 │ success    │ Add CLI           │ clap-complete-1660 │ https://github.com │
│   │            │ completions       │ 8                  │ /iesahin/xvc/actio │
│   │            │                   │                    │ ns/runs/1302755462 │
│   │            │                   │                    │ 2                  │
╰───┴────────────┴───────────────────┴────────────────────┴────────────────────╯

🐢 The earlier one has passed. It looks like we’re ready to merge. Let’s update the CHANGELOG.md for release.

🐇 Setting the release version:

cargo set-version "0.6.14"
   Upgrading xvc from 0.6.14-alpha.10 to 0.6.14
...

🐢 Let’s check the CI

$ ghrl | first 2

╭───┬────────────┬───────────────────┬────────────────────┬────────────────────╮
│ # │ conclusion │   displayTitle    │     headBranch     │        url         │
├───┼────────────┼───────────────────┼────────────────────┼────────────────────┤
│ 0 │ success    │ Add CLI           │ clap-complete-1660 │ https://github.com │
│   │            │ completions       │ 8                  │ /iesahin/xvc/actio │
│   │            │                   │                    │ ns/runs/1302770108 │
│   │            │                   │                    │ 2                  │
│ 1 │ success    │ Add CLI           │ clap-complete-1660 │ https://github.com │
│   │            │ completions       │ 8                  │ /iesahin/xvc/actio │
│   │            │                   │                    │ ns/runs/1302755462 │
│   │            │                   │                    │ 2                  │
╰───┴────────────┴───────────────────┴────────────────────┴────────────────────╯

🐇 And merge:

$ ghpM --body $"(open CHANGELOG.md | lines | skip 2 | take 7)" --subject "Add completions" --squash

🐢 Tagged main and pushed. Packages should be built in a few minutes.

🐢 Instead, we can make it test with environment variables for each of these shells.

🐇 It looks like the test fails with wait_status.

cargo test -p xvc --test test_completions
...
failures:

---- test_completions stdout ----
...
ExitStatus(unix_wait_status(512))

thread 'test_completions' panicked at lib/tests/common/mod.rs:46:5:
Command failed: Command { cmd: "/Users/iex/github.com/iesahin/xvc/target/debug/xvc", stdin: None, timeout: None }
...

🐢 The failure is in the line:

    let mut cmd = Command::cargo_bin("xvc").unwrap();

So it probably waits for user input to complete, but it doesn’t have any and cannot complete it, so it returns an error.

🦊 Let’s comment the earlier test out and check if other tests work.

🐢 Yes, they fail the same. When there are no commands to run, xvc returns an error. Maybe we can change this behavior or handle the error in the Command::cargo_bin line above.

🐇 I checked the code and we don’t handle the “no arguments” case anywhere. It looks like the behavior to return an error code is inherited from clap.

🐢 Updated the error handling code to report a more descriptive message from the source.

cargo test -p xvc --test test_completions
...
failures:

---- test_completions stdout ----
Output { status: ExitStatus(unix_wait_status(25856)), stdout: "", stderr: "\nthread 'main' panicked at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.5.20/src/builder/debug_asserts.rs:341:13:\nCommand pipeline: command `export` alias `l` is duplicated\nstack backtrace:\n   0: rust_begin_unwind\n             at /rustc/b1a7dfb91106018f47ed9dc9b27aee1977682868/library/std/src/panicking.rs:692:5\n   1: core::panicking::panic_fmt\n             at /rustc/b1a7dfb91106018f47ed9dc9b27aee1977682868/library/core/src/panicking.rs:75:14\n   2: clap_builder::builder::debug_asserts::assert_app\n             at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.5.20/src/builder/debug_asserts.rs:341:13\n   3: clap_builder::builder::command::Command::_build_self\n             at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.5.20/src/builder/command.rs:4173:13\n   4: clap_builder::builder::command::Command::_build_recursive\n             at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.5.20/src/builder/command.rs:4076:9\n   5: clap_builder::builder::command::Command::_build_recursive\n             at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.5.20/src/builder/command.rs:4078:13\n   6: clap_builder::builder::command::Command::build\n             at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.5.20/src/builder/command.rs:4071:9\n   7: clap_complete::env::CompleteEnv<F>::try_complete_\n             at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_complete-4.5.40/src/env/mod.rs:229:9\n   8: clap_complete::env::CompleteEnv<F>::try_complete\n             at /Users/iex/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_complete-4.5.40/src/env/mod.rs:210:9\n   9: xvc::main\n             at ./src/main.rs:18:30\n  10: core::ops::function::FnOnce::call_once\n             at... [truncated]
ExitStatus(unix_wait_status(25856))

...

error: test failed, to rerun pass `-p xvc --test test_completions`

🐢 The real issue is when we assert the successful run, at this line:

            assert!(output.status.success(), "Command failed: {:?}", prepared);

🐇 If you look at the error message carefully, you’ll see that this is a different error. We added an alias to xvc pipeline export with l, which is a duplicate.

🐢 Oops, yeah.

cargo test -p xvc --test test_completions
...
test test_completions ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.81s

🐇 There are some warnings in compilation. Let’s fix these.

cargo build
   Compiling xvc-storage v0.6.14-alpha.8 (/Users/iex/github.com/iesahin/xvc/storage)
   Compiling xvc-file v0.6.14-alpha.8 (/Users/iex/github.com/iesahin/xvc/file)
   Compiling xvc-pipeline v0.6.14-alpha.8 (/Users/iex/github.com/iesahin/xvc/pipeline)
   Compiling xvc v0.6.14-alpha.8 (/Users/iex/github.com/iesahin/xvc/lib)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.28s

🐢 Finished the build without warnings. Now we can run the whole test suite again.

🐇 Tests are running fine. Updated some error messages and types, and doc tests also pass. There is an issue with the Rsync storage ref.

🐢 It looks like we try to elide output with [...], while the proper format is [..].

🐇 Replaced them with ... that will elide multiple lines.

🐢 Pushed changes to the server.

🐇 It looks, from the coverage page, that our additions to HStore don’t have any tests. Maybe we can add some unit tests to the new joins.

🐢 I don’t find unit tests particularly useful, but let’s use GitHub Copilot to add some for us.

🐇 I added a unit test and a doc test for full_join. I think doc tests have more value; they provide documentation, and we can readily see how to use a function from its docs. It’s better to increase coverage with doc tests.

🐢 There are things I should keep in mind while writing doc tests. Imports must use the full path, not crate. Also, the tested struct doesn’t have implicit imports.

🐇 The ceremony for adding keys and values is a bit too much. It might be worthwhile to add an insert method for anything that implements Into<XvcEntity>.

🐢 That would certainly save time—no more typing .into() for each key! :)

🐇 Pushed to test again. Should we have some way to test coverage locally?

🐢 I don’t think we need to check coverage locally. It’s not worth our time right now.

🐇 Now, while waiting for the tests to complete, what else can we do?

gh -R iesahin/xvc run list
completed failure v0.6.13 Rust-CI v0.6.13 pull_request 12543831360 3m54s 2024-12-30T08:15:06Z
...

🐢 That didn’t take too long. Let’s view the results:

gh -R iesahin/xvc run view 12543831360
...
  X Run Current Dev Tests
...
To see what failed, try: 
View this run on GitHub: https://github.com/iesahin/xvc/actions/runs/12543831360

🐢 The current dev tests are failing for some reason. Let’s run them locally.

🐇 We’re missing llvm-tools-preview locally. How do I install this?

🐢 The command is rustup component add llvm-tools-preview:

info: component 'llvm-tools' for target 'aarch64-apple-darwin' is up to date

🐇 It’s already installed. We just need to set the environment variables.

🐢 Instead, we can just turn off dev tests for the time being. We don’t really need them; our local tests pass.

🐇 Yeah, okay. We don’t need to solve every single bit of these issues right now.

gh -R iesahin/xvc run list
...

🐇 Okay, let’s take a look at the run again.

gh -R iesahin/xvc run list
completed failure v0.6.13 Rust-CI v0.6.13 pull_request 12544020064 3m39s 2024-12-30T08:33:25Z

gh -R iesahin/xvc run view 12544020064
...
  X Test and Coverage
...

gh run view 12544020064 --log-failed
...
Test and Coverage (stable) Test and Coverage 2024-12-30T08:36:58.8911690Z Error: ProcessError { stdout: "", stderr: "  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\ncurl: (7) Failed to connect to e1.xvc.dev port 80 after 160 ms: Couldn't connect to server\n" }
...

🐢 We need to start Nginx on the server. We forgot to do that yesterday.

🐇 Ah, right. After that dufs installation. Okay.

🐢 We also need to add a reverse proxy for dufs somehow, but that’s for later.

🐇 For this use case, I don’t think it’s necessary. We can just adjust the port to a non-standard one if we need 443 for something else. Let’s look at the tests again.

🐢 Let’s add another doc test, this time to XvcStore.

cargo test -p xvc-ecs --doc
...
test result: ok. 8 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 2.87s

🐇 Sent the files again. Waiting for the tests to finish.

🐢 Let’s check the keymaps file in the meantime.

🐇 I tried reading the documentation but didn’t see an error. Maybe we should just set it to non-lazy and disallow remaps.

🐢 We’ve already spent too much time on this.

🐇 Yes, let’s check the tests again.

gh -R iesahin/xvc run list
completed success v0.6.13 Rust-CI v0.6.13 pull_request 12544291068 8m10s 2024-12-30T09:00:42Z
...

🐢 Oh, nice, the merge is ready.

🐇 Patch coverage is still behind the target, though.

🐢 Yeah, but let’s release this one and ensure the next one is better covered. Also, I’m not sure if the doc tests actually affected the coverage report.

🐇 If we look at the coverage page again, we can see.

🐢 It seems codecov.io doesn’t consider coverage for doc tests. That’s a bit weird, but let’s not spend more time on it.

🐇 Sure, let’s merge.

🐢 I think we forgot to bump the versions in the Cargo.toml files. We’ll have to do that in main.

🐇 Oh, yeah. Let’s bump them and tag the release as well.

🐢 Now we can wait for all the files to be produced. What’s next?

🐇 We can release the Python version too. It shouldn’t need any changes.

🐢 Right. Maybe we can add a few tests there as well.

🐇 Let’s bump the version first and see.

🐢 I’ve bumped the versions in Cargo.toml and run maturin develop.

🐇 It seems ready now.

🐢 The main branch is failing, though. The “Publish crates” action is looking for libsqlite3. Let’s investigate.

gh -R iesahin/xvc run list
completed failure Release v0.6.13 Publish Crates v0.6.13 push 12544753359 6m1s 2024-12-30T09:41:56Z

🐢 The issue is that the VM doesn’t have libsqlite3-dev. Let’s add it.

🐇 We need to restart the job manually. Let’s skip tagging this time.

🐢 Some of the packages were already published, and now they’re causing failures because crates.io says they already exist. Maybe we can check if a package is already published before trying.

🐇 Let’s see if we can make cargo publish more forgiving.

🐢 There doesn’t seem to be an easy option. Let’s search for “how to skip published packages in workspace to avoid errors with cargo publish.”

🐇 Claude is hallucinating again. Let’s try a manual approach: how to skip already published packages?

🐢 It might be easier to just add a check. How do we get that info?

🐇 Or we can just move on to the next package if one is already available.

🐢 Let’s push the missing packages manually this time.

🐢 We should have a key to open garden files quickly. What does Fzf-Lua files receive as arguments?

🐇 Let’s check the help page: fzf-lua.

🐢 Before that, maybe we can try to fix why selected lines are not searched in Visual-Line mode?

🐇 Yep, let’s fix our search first.

🐢 How do you set a key in visual line mode in Neovim Lua?

🐇 The abbreviation is V. Let’s try that.

🐢 Looks like we need to restart the session.

🐇 It’s still not working. Let’s check :map.

🐢 It seems it needs more care; I’ll check it later.

👨🏾‍🦲 🐢 Bence kendini biraz daha anlamlı bir işle uğraştırmalısın. 🐇 Ne gibi? 🐢 Belki biraz daha yayın yapmalısın, biraz daha işe başvurmalısın. 🐇 “Meli”, “malı” ile geçiyor ömrümüz.

⌚ 🐢 It looks like we can move most of the daily template to links or commands. We can call it ref/daily. My idea is to fill the page intentionally, without templates.

🐇 It might be better to start with a blank page, yeah. The template makes me a bit nervous. There are too many things to fill in, and most of them aren’t things I like being pushed into doing.

🐢 Let’s start by moving the daily templates to ref/daily. No more daily template.

🐇 Now we can delete the rest of this page. We’ll use the daily links page and maybe have reminders at the end of these sessions.

👨🏽‍⚕️

I tried the same approach when testing Python bindings with Pytest:

def test_pipeline_step_dependency(empty_xvc_repo):
    dep_help = empty_xvc_repo.pipeline().step().dependency(help=True)
    expected = """
Usage: xvc pipeline step dependency [OPTIONS] --step-name <STEP_NAME>

Options:
  -s, --step-name <STEP_NAME>
          Name of the step to add the dependency to
"""
    assert dep_help == expected

This doesn’t work because the help text is generated by clap and skips the usual thread-based output handler. All command output and errors in Xvc are returned as strings from the command, except for the help text that’s generated by clap automatically.

There are probably workarounds for this, but I won’t pursue them further as I don’t test the actual functionality in the Python bindings anyway.

The single-loader allows only one instance of Xvc to be run in a single process. This is no problem for the shell, but it looks like it won’t be possible to use multiple Xvc instances in a single Python process.

It’s possible to overcome this with an elaborate multiprocessing setup in the wrapper, but I won’t bother with it for now.

🐢 The tests for yesterday’s Git integration PR failed. I’ll begin by checking the logs.

🐇 Maybe run the tests locally to see. They might fail on your machine as well. It might be a simple thing.

🐢 Probably, yes. I’ve started the tests now. I shouldn’t forget to run them before testing the PR; it may save some time.

🐇 Ah, yeah, maybe. Yesterday you were already at the end of the workday, so it didn’t matter much. But you can shorten the testing time by reducing the number of files, etc. I think a separate benchmark suite might be good to have. Tests should be shorter; benchmarks should only run for tags.

🐢 Yup. I should shorten the tests. I should make them use a shorter list of files, maybe.

🐇 Local tests have passed. You’ll have to check the logs.

🐢 It seems git diff --name-only --cached returns files not yet added. That’s causing an error in new repositories with stash. Stashing shouldn’t run at all when there are no staged files.

🐇 Git behavior between the local version and the remote version seems different.

🐢 I think the trace should also show the Git version string.

🐇 You should also require a minimum Git version for the commands. You’re using some newer options, and not all users may have them.

🐢 Yep. Let’s see the version on the CI now.

🐢 Ah, I see—the problem is not about versions. It’s that the CI doesn’t configure git config --global user.email and user.name. Commits don’t work without these.

🐇 You should remove the Git version report, then. It’s one more process call for no reason.

🐢 I think it should be in trace!; I can check the verbosity level and call it only if it’s trace.

🐢 I completed the xvc-config docs as well. I think I can merge it before the tests finish, as it’s just a documentation update.

🐇 You seem to be rushing for the release.

🐢 Yeah, I want to really start testing this on the servers.

🐇 Then go ahead; let’s release a new version.

🐇 It looks like you’re back for an evening session. I think it’s time to start using Xvc on your torrent server.

🐢 Ah, yeah. Let’s see how it goes.

🐇 Create a repository for torrents. Then you can add files to it with cache-type = symlink or cache-type = hardlink.

🐢 I think creating a local storage may also help. I can use it to store files to retrieve them later.

🐇 Umm. We don’t have a “garbage collection” facility yet, you know. There are no file deletions at the moment. It may be better to have a repository-to-repository transfer feature, using SSH.

🐢 Yeah, we don’t have SSH storage either. I think this highlights a lack of features.

🐇 It’s possible to mimic Rsync storage with xvc storage new generic, but it doesn’t feel quite the same.

🐢 Then I’m adding these three tickets.

🐇 I think for 0.3.4, the command we add might be xvc file delete. You can work on this and add rsync support as well.

🐢 There is a librsync bindings library for Rust. But it looks like it doesn’t allow transferring file contents between hosts. There is also rusync, which is similar to rsync and implemented in Rust. There is also fast_rsync in pure Rust. It uses MD4 to calculate deltas, though, I think.

🐇 None of these seem to have network capability, though.

🐢 I think it’s better just to use the process for now. We are trying to come up with the simplest solution for now. We are just trying to be more general.

🐇 Yes, I think we can just use the process for the time being.

🐢 Then let’s start by adding it.

🐇 We should also begin to create release notes. GitHub can generate them from PRs. Automatically generated release notes

🐢 Created an issue for that. Now we’re starting xvc storage new rsync #111.

🐇 Ok. Let’s do this.

🐢 Yep. It was a nice October. I would like to finish by increasing the coverage.

🐇 How about setting up a runner on your machine to test them locally?

🐢 Not now. I should fix the tests as always. Later I can take a look at it. I don’t want to distract myself with it.

🐇 You’ll need to create Apple Silicon binaries, though.

🐢 I think I can cross-compile for aarch.

🐇 You were doing this in the past, trying to build all binaries on a single Ubuntu VM. It didn’t work, as far as I remember.

🐢 I hadn’t even read this section then, and there is a dedicated project for it. The proper way is to use that. I’ll return to this after fixing the tests. I think we can release Xvc on all platforms supported by Rust.

🐇 Using cross-rs on GitHub Actions may be challenging. It seems Apple Silicon doesn’t need that much work either. You can set up cross-compilation with rustup targets.

🐢 Yeah. It looks so. Let’s take a look at the previous devlog.

🐇 The page seems missing. Would you like to fix your site first?

🐢 Ah, yeah. I should, maybe. Now it’s time to fix those PRs. I’ll take care of the site later. I should change the theme anyway.

🐇 Ok. Let’s take a look at outstanding PRs.

🐢 I want to fix the failed tests locally first. Yesterday I wasn’t able to redirect the output. It looks like the correct way of doing it is cargo test --all-features --no-fail-fast > $TMPDIR/xvc-test.log 2>&1. It’s required to put 2>&1 at the end, not between the redirection and output.

🐇 There is also the &> operator that you may want to use. cargo test --all-features --no-fail-fast &> $TMPDIR/xvc-test.log should be equivalent to this.

🐢 I’ll try it when the tests finish.

🐇 In the meantime, you can work to fix the documentation. In another repository, perhaps.

🐢 Good idea. Let me clone that.

🐇 Looks like the tests have finished and the only error is Minio. It couldn’t find the env variables you defined.

🐢 Restarted the shell and the tests. Returned to docs now.

🐢 Added a few function docs. Storage tests seem to pass. Probably they will fail in GA because of rsync tests using one.emresult.com login in my name.

🐇 If that’s expected, you can push and begin to fix it.

🐢 Yeah, let’s push the tests.

🐢 It looks like connecting to localhost also poses a challenge. Instead, I can create a user for xvc on the server and limit its usage.

🐇 Hmm. Good idea for now.

🐢 I created a new user xvc-test@one.emresult.com and its SSH keys. I’ll update the action to write the secret to the keyfile.

🐇 Looks like you forgot to install mc for Minio connection.

🐢 Yeah, I must convert Minio tests to use s3cmd.

🐇 And your region in s3 configuration seems to be wrong.

🐢 I’ll need to check this.

🐇 There is this line in the tests let region = env::var("AWS_DEFAULT_REGION").unwrap_or("us-east-1".to_string()); that’s probably causing that error. You should define the region properly.

🐢 I set this to eu-central-1 directly and will check the Minio error in the next session.

🐇 👏

🐢 It’s working except for the rsync tests now.

🐇 I think you can just use localhost to run the tests. You may need to install openssh-server, but it should work with localhost without configuration.

🐢 There may be a step missing in the configuration. I’ll try to make it run.

🐢 I’m trying to use .ssh/config in GA to allow connections to the server. It doesn’t work for some reason.

🐇 You may try to log in to the server outside of the tests and check if it’s running.

🐢 Yesterday’s last attempt was successful, and now we have working remote storage tests.

🐇 👏👏👏🥳

🐢 I’m merging the PR.

The one that is most proven and ready to scale is based on a technology called LSPR. The team building it originally developed the device to monitor the status of the immune system, but it is easily adapted to detect the proteins on the surface of the virus instead of the proteins used for immune signaling. It’s able to detect even a very small number of viral particles, which is very important because we want to detect everyone who is contagious. Waiting for symptoms such as a fever or antibodies is too slow to stop the spread. What’s exciting is that they are creating a very sensitive test that can be mass produced at low cost (less than $1/test).

In Android, one needs to put unit test files in the app/src/test/*module-name* directory. I spent a few hours yesterday writing tests to check that the conversion between visenc and Unicode is correct in Android. After those hours, however, I learned that NDK support for tests is limited, and the error I received means that I need to write instrumentation tests instead, which use an emulator or a real device.

Instrumentation tests are user tests that check whether the user-facing aspects of the app run correctly. Unit tests, instead, check whether data flow, calculations, etc., are working as expected. The former is slow; it needs to be run in an emulator and should mimic user behavior. Just checking whether e converted correctly to ا should not require an emulator.