Feature request: count lines of tests code

[gww-certik]

Feature request: ability to count (maybe via optional flag --count-tests) lines of code that belong to tests.

[cycle20]

Why don't you separate those analysis?
For example:

find src \
  -name "*.js" \
  -o -name "*.ts" \
  -o -name "*.php" \
  -o -name "*.bash" \
  | xargs scc

find test-e2e test-unit \
  -name "*.js" \
  -o -name "*.py" \
  -o -name "*.ts" \
  -o -name "*.php" \
  -o -name "*.bash" \
  | xargs scc

Furthermore --count-tests seems quite under-specified: there might be various project layouts and naming conventions.
Maybe *test* pattern can refer to test code hierarchy or a feature module of unit test framework, statistical library etc. in the name of a directory.

[gww-certik]

In Rust tests are in same file , usually between :

#[cfg(test)]
mod tests {
...
}

https://doc.rust-lang.org/stable/rust-by-example/testing/unit_testing.html

[cycle20]

In Rust tests are in same file , usually between :

Wow. Great. 🤔
Is it a legacy code?
Is there any chance to use integration tests instead of private testing of private code?
https://doc.rust-lang.org/stable/rust-by-example/testing/integration_testing.html

NOTE: I am not familiar with Rust at all.

[gww-certik]

Putting tests on bottom of files is Rust idiomatic. So tests are close to code they relate to and easier to keep up to date.

…

On Sat, 27 Nov 2021, 11:02 Csongor T. G., ***@***.***> wrote: In Rust tests are in same file , usually between : Wow. Great. 🤔 Is it a legacy code? Is there any chance to use integration tests instead of private testing of private code? https://doc.rust-lang.org/stable/rust-by-example/testing/integration_testing.html NOTE: I am not familiar with Rust at all. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWLS4N4PUZXPRSQRX37GJXLUOCUEBANCNFSM5IX2IEVQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[boyter]

Been thinking about this. I think it might be best served by what I was planning on doing eventually and have custom parsers for the more common file types. The reason being the languages.json works well for generic languages, but some such as Java, C, PHP, Python, Rust etc... could get some performance gains out of a specific parser for them.

In addition it would allow for some modifications such as this.

Now where I can see this being problematic is how it gets reported, as it would mean either reporting 2 lines in the output per language where this happens, or via adding a new column.

Consider the following,

$ scc --by-file
───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go                          53      9510     1370       809     7331       1358
───────────────────────────────────────────────────────────────────────────────
service/search.go                   1061      142       134      785        159
data/models/code.go                  736       72        13      651         71
service/search_test.go               434        8         0      426          2
service/background_cloner.go         431       73        45      313         92
index/caisson_test.go                420       75        25      320         63

Knowing where to put the new format is a problem there. Say I put the tests into service/search.go where should the test count go? I don't think another column is appropriate since tests can have blank lines or comments as well, but a new row is problematic too because where do the counts go? It also makes sorting a bit painful but thats not a huge issue.

Tokei might have the answer because it checks some language types for other languages and reports on them such as this,

$ tokei
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 HTML                   37         2021         1737           15          269
 |- JavaScript           2          366          295           13           58
 (Total)                           2387         2032           28          327

Which is a possibility although I am not sold on it. Its the best I can think of at the moment though.

[gww-certik]

There is one more aspect to it. If I count statistics, I would like to know how many lines are there of : code & comments in code; tests & comments in tests;

…

On Mon, Nov 29, 2021 at 2:23 AM Ben Boyter ***@***.***> wrote: Been thinking about this. I think it might be best served by what I was planning on doing eventually and have custom parsers for the more common file types. The reason being the languages.json works well for generic languages, but some such as Java, C, PHP, Python, Rust etc... could get some performance gains out of a specific parser for them. In addition it would allow for some modifications such as this. Now where I can see this being problematic is how it gets reported, as it would mean either reporting 2 lines in the output per language where this happens, or via adding a new column. Consider the following, $ scc --by-file ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blanks Comments Code Complexity ─────────────────────────────────────────────────────────────────────────────── Go 53 9510 1370 809 7331 1358 ─────────────────────────────────────────────────────────────────────────────── service/search.go 1061 142 134 785 159 data/models/code.go 736 72 13 651 71 service/search_test.go 434 8 0 426 2 service/background_cloner.go 431 73 45 313 92 index/caisson_test.go 420 75 25 320 63 Knowing where to put the new format is a problem there. Say I put the tests into service/search.go where should the test count go? I don't think another column is appropriate since tests can have blank lines or comments as well, but a new row is problematic too because where do the counts go? It also makes sorting a bit painful but thats not a huge issue. Tokei might have the answer because it checks some language types for other languages and reports on them such as this, $ tokei =============================================================================== Language Files Lines Code Comments Blanks =============================================================================== HTML 37 2021 1737 15 269 |- JavaScript 2 366 295 13 58 (Total) 2387 2032 28 327 Which is a possibility although I am not sold on it. Its the best I can think of at the moment though. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWLS4NYSPJZJCO5JUE2UP2TUOLI2JANCNFSM5IX2IEVQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[boyter]

I just added the ability to exclude based on filename patterns, so for go you could exclude tests using the below

scc -n _test.go

You can also supply multiple

scc -n _test.go,main.go

The above would not count any main.go files or files containing _test.go.

Added because I needed it. But I thought it might be useful for this case as well. You will need to build off master to get this but if you are in a bind it might help.

[lcmgh]

So far I could not find any tool that supports ignoring Rust test code so I am upvoting this.