> On Tue, Jul 15, 2014 at 5:25 AM, Christoph Husse > <thesaint1...@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. -- Andrew Poelstra Mathematics Department, University of Texas at Austin Email: apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew "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
pgpjeUsJTwD29.pgp
Description: PGP signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
