devlog 19

Emre Şahin — 2025-01-29T09:19:56+00:00

🐇 Let’s start by checking the GitHub Actions results.

$ 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.

Unit tests vs Integration Tests in Rust

Emre Şahin — 2022-06-11T05:55:58+00:00

One thing I’ve noticed since I started working with Rust is that Test-Driven Development (TDD) has become much more feasible. As a developer who is “absentminded by default,” I highly value tests. However, if the feedback cycle is slow, it becomes prohibitively expensive to test everything. This is likely why unit tests are often favored over integration tests: they are more precise, faster to execute, and make rapid round-trip testing more achievable.

Another point is that Rust, being a statically typed language, requires far fewer unit tests than dynamic languages. Traditionally, unit tests are used to validate “input consumption” (ensuring input is processed correctly) and “well-formed output” (verifying that the output meets requirements under specific conditions). In Rust, many of these input-output concerns are resolved at compile time through the use of expressive types like structs and enums.

For these reasons, I find myself more inclined toward integration tests that reflect real-world requirements, rather than focusing solely on unit tests in artificial settings.

emre şahin's digital garden 🍃 - tdd

devlog 19

Unit tests vs Integration Tests in Rust