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.
@TensorProgramming4 жыл бұрын
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"].
@brunoduncan23813 жыл бұрын
I guess I'm kinda randomly asking but do anyone know of a good place to watch newly released movies online?
@claytonspencer15063 жыл бұрын
@Bruno Duncan Flixportal
@brunoduncan23813 жыл бұрын
@Clayton Spencer thank you, I went there and it seems like a nice service :) I appreciate it !!
@claytonspencer15063 жыл бұрын
@Bruno Duncan Glad I could help =)
@CGMossa4 жыл бұрын
It is great to see that you're making Rust videos again!
@TensorProgramming4 жыл бұрын
There are more to come. I want to finish my Async/Await series and add a more advanced testing video.
@marcusradell75444 жыл бұрын
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
@TensorProgramming4 жыл бұрын
I have videos on hexagonal architecture.
@jatmikoherjati63484 жыл бұрын
Always supporting Rust Community ! Yeaa
@LassNoches2 жыл бұрын
Thanks Tensor, your videos is helping me a lot. Regards from Brazil.
@TensorProgramming2 жыл бұрын
glad you like the content. Good to know it makes it to the world overall.
@learnityourself4 жыл бұрын
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.
@TensorProgramming4 жыл бұрын
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.
@KevinDay4 жыл бұрын
@@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.
@TensorProgramming4 жыл бұрын
@@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.
@hubstrangers34504 жыл бұрын
Thank you for the content, and looking forward further content on this topic ..... thanks again
@TensorProgramming4 жыл бұрын
There is much more on the way for both Testing and Rust.
@yousufuyghur4 жыл бұрын
Hi! Will you use Rust for embedded systems as well? Would love to see your videos!
@TensorProgramming4 жыл бұрын
Hmm perhaps. I may do some kernel stuff and some basic system level stuff in the future.
@pheel_flex4 жыл бұрын
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
@TensorProgramming4 жыл бұрын
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.
@patatasdelpapa4 жыл бұрын
Correct me if I'm wrong but in 15:10 you couldn't have done v.iter().sum()?
@TensorProgramming4 жыл бұрын
Yes I could have used the built in method. I chose not to because its not as explicit.
@ZigzauerLT4 жыл бұрын
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_net4 жыл бұрын
Hi dear friend thank you so much for sharing this video