chore: fmt to capture Writer

[ssddOnTop]

related to #2640

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 49 lines in your changes missing coverage. Please review.

Project coverage is 87.40%. Comparing base (e10eab5) to head (94b163f).
Report is 15 commits behind head on main.

Files with missing lines	Patch %	Lines
src/cli/fmt.rs	0.00%	25 Missing ⚠️
src/cli/tc/check.rs	0.00%	10 Missing ⚠️
src/cli/tc/helpers.rs	0.00%	9 Missing ⚠️
src/cli/tc/start.rs	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2644      +/-   ##
==========================================
- Coverage   87.49%   87.40%   -0.09%     
==========================================
  Files         263      263              
  Lines       26523    26549      +26     
==========================================
  Hits        23205    23205              
- Misses       3318     3344      +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.

[tusharmath]

Lets connect on this when you are back.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.

[github-actions]

PR closed after 10 days of inactivity.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.

[meskill]

Do we really need to capture the output separately?

Consider this:

• instead of calling some function from the lib we can start the binary programmatically and capture it's output.
• also we can use different tracing crates to capture the output for testing, but I don't think making changes to the code to test the cli output is a good approach

[ssddOnTop]

* instead of calling some function from the lib we can start the binary programmatically and capture it's output.

but is that a good approach?

we couldn't get codecov, if something throws an runtime error, we won't have much information about that.. etc

[meskill]

* instead of calling some function from the lib we can start the binary programmatically and capture it's output.

but is that a good approach?

we couldn't get codecov, if something throws an runtime error, we won't have much information about that.. etc

I believe it'd better represent end user experience and we will test the actual output instead of testing that some data has been written somewhere that won't mean the actual output (for testing TAILCALL_LOG).
Also, code coverage is possible for standalone binaries though it's probably not that easy to collect, agree

[ssddOnTop]

I believe it'd better represent end user experience and we will test the actual output instead of testing that some data has been written somewhere that won't mean the actual output (for testing TAILCALL_LOG). Also, code coverage is possible for standalone binaries though it's probably not that easy to collect, agree

Okay.

Closing this PR and I'd raise new PR based on the suggestions.

[meskill]

I believe it'd better represent end user experience and we will test the actual output instead of testing that some data has been written somewhere that won't mean the actual output (for testing TAILCALL_LOG). Also, code coverage is possible for standalone binaries though it's probably not that easy to collect, agree

Okay.

Closing this PR and I'd raise new PR based on the suggestions.

Please discuss first with @tusharmath about the approach