Reusable vector module with tests
Unit tests should be put in the file they're testing

It's recommended to put the unit tests into the same file as the functions you're testing. This prevents your code from getting out of sync with your tests more easily. Also, you don't want one single large tests.rsfor all your unit tests.

Use proper types in traits

At the moment, as soon as we use any function from Vector3, we end up with a KVector3:

pub trait Vector3 {
    fn dot(&amp;self, v : KVector3) -&gt; f64;
    fn cross(&amp;self, v : KVector3) -&gt; KVector3; // here

    fn zero() -&gt; KVector3;  // here
    fn i_hat() -&gt; KVector3; // here
    fn j_hat() -&gt; KVector3; // here
    fn k_hat() -&gt; KVector3; // here
}


That's probably not what you intended. Use Self instead here. Furthermore, all your functions are fixed to f64, but one can implement all functions from Vector3 for any number type. The following interface encapsulates that:

pub trait Vector3 {
    type Output;

    fn dot(&amp;self, v: Self) -&gt; Self::Output;
    fn cross(&amp;self, v: Self) -&gt; Self;

    fn zero() -&gt; Self;
    fn i_hat() -&gt; Self;
    fn j_hat() -&gt; Self;
    fn k_hat() -&gt; Self;
}


Use derive for canonical implementations

If you use #[derive(PartialEq, Debug)] you don't have to implement both variants yourself.

Consider generics for your structs (and traits)

Your KVector3 only supports f64. However, we can imagine a situation where we want to store f32, for example for GPU calculation. We can use KVector3 also in that circumstance if we make it generic.

Add documentation and examples

Since you're working on a reusable library you want to have some documentation at hand. Furthermore, examples in your documentation are automatically checked with cargo test.