Rust Testing and TDD - An Intro to Testing and Test Driven Development

[@Parker8752]

Just a couple of things I would note - typically, when doing TDD, you would put each test into its own function. You would also want test for error results - for example, what might happen if someone added "apples" into the file you're reading from? That's something that would have its own test. For those new to the idea of TDD, the points of it is that you write out the expected behaviour before you write out the logic that brings the behaviour about. As such, you write just enough of a test to fail, and then write the minimum possible code to make the test pass. Rinse and repeat. To take it to its most extreme, if you were writing a function that adds two integers, the test would first consist of one line: "let result = "add(5, 10);". Then, you write the add function with one line: "0". Next, you write the next line of the test: "asserteq!(result, 15);", and replace the 0 in the add function with a 15 (running tests between edits). Then, you write a new test that adds two different numbers together (say, 5 and 7). At that point, you finally replace the hard coded result in the add function with "a + b". Then, you might add a test that detects what happens if you take the maximum value of an integer, then add one. In Rust, this will result in an overflow, which will cause a panic (and thus fail the test), so you then decide what you want the result to be - maybe you want to ensure that anything that would overflow returns the maximum value, for example, before adding more code into the function that does so. Alternatively, you might decide that panicking is exactly what the code should do, and so you specify in the test that a panic is expected behaviour. This is, of course, a pretty extreme example, just for illustration. The idea here is that you think about what should happen during routine use, write just enough of a test to fail, write just enough code to make the test pass, and keep on going until the expected behaviour is there and is guaranteed to work. Then, you think about the edge cases, write just enough of a test to fail in the edge case, then write the code to deal with the edge case. As a result of the extra work up front, you end up with a series of tests that both describe the expected behaviour of a piece of code, and ensure that the behaviour remains as expected, meaning that you don't end up with extra work later on when changing things might actually be more difficult.

[@TensorProgramming]

Pretty succinct and well thought out explanation. I would also note that generally when writing tests, you want to avoid side effects. I know I didn't do this in this particular example, but that was primarily because I wanted to avoid explaining mocks and other more advanced testing techniques in this video. As you mentioned, tests that deliberately fail can be just as useful as test that pass. In Rust, theres a proc macro #[should_panic] which you can put at the top of a test that will fail. You can also add the error message that you are expecting from the panic like so: #[should_panic = "some error code"].

[@brunoduncan2381]

I guess I'm kinda randomly asking but do anyone know of a good place to watch newly released movies online?

[@claytonspencer1506]

@Bruno Duncan Flixportal

[@brunoduncan2381]

@Clayton Spencer thank you, I went there and it seems like a nice service :) I appreciate it !!

[@claytonspencer1506]

@Bruno Duncan Glad I could help =)

[@CGMossa]

It is great to see that you're making Rust videos again!

[@TensorProgramming]

There are more to come. I want to finish my Async/Await series and add a more advanced testing video.

[@marcusradell7544]

This video was exactly what I needed! I do agree on the need of a hexagon pattern video, mostly so we can see how to write adapters for our tests. Thanks for all your effort

[@TensorProgramming]

I have videos on hexagonal architecture.

[@jatmikoherjati6348]

Always supporting Rust Community ! Yeaa

[@LassNoches]

Thanks Tensor, your videos is helping me a lot. Regards from Brazil.

[@TensorProgramming]

glad you like the content. Good to know it makes it to the world overall.

[@learnityourself]

Thanks again for all the content on rust. I was wondering if you could do a hexagon pattern as you did for go but just for rust I think it would be a good topic.

[@TensorProgramming]

Hexagonal microservices in Rust are possible but its a completely different ball of wax compared to Go. With Go you can do all kinds of stuff with interfaces where as Rust Traits are a bit more restrictive. At some point I may do something like that tutorial in Rust.

[@KevinDay]

@@TensorProgramming The fact that it's more difficult in Rust might actually be good for demonstrating the differences between Rust and other languages, and showing ways to work around/with its restrictions.

[@TensorProgramming]

@@KevinDay Its not difficult its just different. Rust wasn't really made for Net or I/O purposes as its first class use-case. This is part of why its taken them so long to release an async API.

[@hubstrangers3450]

Thank you for the content, and looking forward further content on this topic ..... thanks again

[@TensorProgramming]

There is much more on the way for both Testing and Rust.

[@yousufuyghur]

Hi! Will you use Rust for embedded systems as well? Would love to see your videos!

[@TensorProgramming]

Hmm perhaps. I may do some kernel stuff and some basic system level stuff in the future.

[@pheel_flex]

Thanks for the great content! I have a question though: When writing tests for Struct methods, is there a way to avoid creating an instance of the Struct in the test function? It just doesn't feel right to do that

[@TensorProgramming]

You can mock the struct but usually its best to just create an instance. With that kind of thing you can extract away the logic into a helper function if you need to use it over and over again in multiple tests.

[@patatasdelpapa]

Correct me if I'm wrong but in 15:10 you couldn't have done v.iter().sum()?

[@TensorProgramming]

Yes I could have used the built in method. I chose not to because its not as explicit.

[@ZigzauerLT]

Thank you!

[@tubex1300]

is there any book for the TDD in Rust Sir? pls give the recommendation

[@TensorProgramming]

In the rust book they have a large section on TDD. I can't think of a book that is specifically about Rust TDD though.

[@Stack_net]

Hi dear friend thank you so much for sharing this video