When I jump into a new codebase, my first instinct is to look over the examples and the unit tests to get a feel for how things are intended to work.
When prototyping, I generally write a few “unit” tests as a form of example code to show basic usage. For example, if I’m writing a compiler for a new toy language, I’ll write some unit tests for each basic feature of the language. If I’m writing networking code (e.g. a game server), I’ll write some client and server tests that demonstrate valid and invalid packets. These generally fall somewhere between unit and integration tests, but I do them in a unit test style. When the project stabilizes, I’ll go through and rewrite those tests to be narrower in scope, broader in line coverage, and simpler, and keep a few as examples (maybe extract to the readme or something).
That’s my workflow, and I like knowing that at least part of it is tested. When I mess with stuff, I have a formal step to change the tests as a form of documenting the change I made, and I’ll usually leave extensive comments on the test to describe the relevance.
Code readability counts, but I don’t think it’s enough. The codebase I work on day to day is quite readable, but it’s very complex since there are hundreds of thousands of lines of code across over a dozen microservices, and there’s a lot of complexity at the boundaries. When I joined the project, I read through a lot of the tests, which was way more helpful to me than reading the code directly. The code describes “how,” but it doesn’t explain “what” or “why.” Tests get into “what” extensively, and “why” can be understood by the types of tests developers choose to write.
For example, if I’m writing a compiler for a new toy language
Ok, thinking about it (since I wrote a toy language not so long ago), this is probably a perfect example where unit tests make sense almost everywhere (even for prototyping, say parser).
I think it definitely depends what you’re doing, writing unit tests for prototype graphics (engine) code is no fun (and I see no real benefit).
Code readability counts, but I don’t think it’s enough.
I think it depends, For general architecture, E2E or integration tests definitely make sense, for finer-grained code, I think documentation (Rust doc) of the functions in question should be enough to understand what they do (including some examples how to use them, could be tests, often examples (similar as in std rust) in the rust doc are enough IMHO, and otherwise the code itself is the documentation (being able to read code fast is a valuable skill I guess). That obviously doesn’t apply for everything (think about highly theoretical computer science or math code), but yeah it depends…
When I jump into a new codebase, my first instinct is to look over the examples and the unit tests to get a feel for how things are intended to work.
When prototyping, I generally write a few “unit” tests as a form of example code to show basic usage. For example, if I’m writing a compiler for a new toy language, I’ll write some unit tests for each basic feature of the language. If I’m writing networking code (e.g. a game server), I’ll write some client and server tests that demonstrate valid and invalid packets. These generally fall somewhere between unit and integration tests, but I do them in a unit test style. When the project stabilizes, I’ll go through and rewrite those tests to be narrower in scope, broader in line coverage, and simpler, and keep a few as examples (maybe extract to the readme or something).
That’s my workflow, and I like knowing that at least part of it is tested. When I mess with stuff, I have a formal step to change the tests as a form of documenting the change I made, and I’ll usually leave extensive comments on the test to describe the relevance.
Code readability counts, but I don’t think it’s enough. The codebase I work on day to day is quite readable, but it’s very complex since there are hundreds of thousands of lines of code across over a dozen microservices, and there’s a lot of complexity at the boundaries. When I joined the project, I read through a lot of the tests, which was way more helpful to me than reading the code directly. The code describes “how,” but it doesn’t explain “what” or “why.” Tests get into “what” extensively, and “why” can be understood by the types of tests developers choose to write.
Ok, thinking about it (since I wrote a toy language not so long ago), this is probably a perfect example where unit tests make sense almost everywhere (even for prototyping, say parser).
I think it definitely depends what you’re doing, writing unit tests for prototype graphics (engine) code is no fun (and I see no real benefit).
I think it depends, For general architecture, E2E or integration tests definitely make sense, for finer-grained code, I think documentation (Rust doc) of the functions in question should be enough to understand what they do (including some examples how to use them, could be tests, often examples (similar as in std rust) in the rust doc are enough IMHO, and otherwise the code itself is the documentation (being able to read code fast is a valuable skill I guess). That obviously doesn’t apply for everything (think about highly theoretical computer science or math code), but yeah it depends…
Yeah, I wouldn’t bother for graphics code either. For that, I want compilable examples, and that’s about it.
I do a lot of math and parsers, and that lends itself very well to unit tests.