[rust-dev] C++ to Rust - Is that about right?
apoelstra at wpsoftware.net
Tue Jul 15 07:18:00 PDT 2014
> On Tue, Jul 15, 2014 at 5:25 AM, Christoph Husse
> <thesaint1987 at googlemail.com> wrote:
> > Further I notices that they often seem to mix test and production code
> > which is also strange to me. For instance with test driven development
> > you have tons of problems with that approach. Only mentioning a few:
> > 1) Test code will most likely be at least in the order of magnitude of
> > the production code it tests, so putting them together in the same
> > directory or even file will get unhandy pretty quickly
You've mentioned file size a few times. In vi you type `:vsplit` to
split your screen into two views of the same file, then you type
`/functionname` in one to go find the relevant function. Alternately,
if your functions are in separate files, you add the relevant file
name to the `:vsplit` command. So the amount of effort spent editing
is basically the same. I expect most IDE's that are not structured
around the C#/Java way of doing things are similarly filesize-agnostic.
On the other hand, /conceptually/ I find Rust's module system to be
much easier to reason about. Even in OO-only languages class boundaries
are typically not functionality boundaries (unless you have monolithic
classes in which only a small subset of functionality is ever used at
any time --- but then you have no modularity, an even worse curse). In
Rust, where precisely-scoped traits provide the majority of functionality,
more than the `struct Struct`/`impl Struct` pairs that are used to
emulate classes, this is even more true.
> > 2) The test code this way can access internals of the module, which by
> > definition should be avoided, since internals are implementation
> > details and if your tests use them you will get cascades of test
> > failures for each simple design change
Well, in your public interface tests, don't use private functions. When
replacing/restructuring private functions, delete the tests which target
those. In other languages I find it very inconvienient to have to switch
contexts to work on tests, and to have no ability to unit test functions
which are not publically exported.
> > 3) Performance, mostly. To have fast iteration cycles, tests most
> > likely need to be grouped an executed/compiled intelligently (which
> > needs some compiler or IDE support) so that only tests that are
> > relevant to the changes you just made will be compiled and executed.
> > If you mix tests with production code then then it is a lot more
> > involved to sieve out tests during compilation, linking and
> > execution... that not need to run.
Well, Rust in general needs some work done on partial compilation :).
I'm sure optimizing test compilation will come as part of that.
Mathematics Department, University of Texas at Austin
Email: apoelstra at wpsoftware.net
"If they had taught a class on how to be the kind of citizen Dick Cheney
worries about, I would have finished high school." --Edward Snowden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: not available
More information about the Rust-dev