Check out a free preview of the full Polyglot Programming: TypeScript, Go, & Rust course:
The "Testing Q&A" Lesson is part of the full, Polyglot Programming: TypeScript, Go, & Rust course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen answers student questions regarding if Rust files can get large due to the tests being included and if naming the functions starting with test_ is just a convention. Questions regarding whether only the macro test is relevant for running tests and the trade-offs of having in-file tests are also covered in this segment.

Get Unlimited Access Now

Transcript from the "Testing Q&A" Lesson

[00:00:00]
>> So there we go. We've just seen testing in all three languages. How does everyone feel about testing and all three languages? Brant, I want you to answer right now. How do you feel about TypeScript?
>> Yeah, that's TypeScript is not enjoyable [LAUGH].
>> All right, is testing enjoyable?

[00:00:18]
>> Yes.
>> Is this the greatest AI generated speech of all time everybody like look at that it's interacting with me.
>> Very realistic.
>> Yeah, but what about Rust, how do you feel about that one?
>> Rust it's pretty awesome. I like that being like in file seems very concise and straightforward to read the test, and that's the problem, I guess with like with TypeScript, that is not super straightforward.

[00:00:40] Using Jest is just challenging.
>> Yeah, there's some rough edges. Obviously, we're doing very simple testing, right? We don't have any mocks going on right now. That's a big thing. We have a question.
>> Someone mentioned that Node 18 now includes a test runner.
>> Nice, Node 18 has a new test, look at that.

[00:01:01] That's pretty awesome. I'm very happy to see that Node is almost 2012, or starting to get there. I'm really proud of them, I know they're gonna nail it. By the way my views do not reflect that of my employer or Frontend Masters. [LAUGH] Is that pretty good? I don't put that in my, people always have that in their Twitter bio, opinions are my own.

[00:01:23] I always find that kind of funny because why aren't they should just be your own, you're not a corporation anyways.
>> Do Rust files get really huge, like all the tests are also in the same file?
>> So they can get larger. I tend to put all my tests at the bottom so it's pretty clear what's happening up at the top.

[00:01:40] And then you have this kinda like nice little demarcation right here, just say, hey, this is what's going on. You could probably fold this. I don't often use folds. I'm not even exactly sure how to fold, but you could just fold this away, right? So it's kind of gone so you don't really see it if you really want to.

[00:01:56] I think it's pretty. I actually like it in the same file because then I don't have to hunt for where the test is. I feel like it's right here. One more question.
>> Is naming the functions test underscore only a convention?
>> Yeah, so let's go foo bar.

[00:02:12] Let's just find out why not, right?
>> Let's go up here and it looks like we had both test and a foo_bar, pass, and that so yeah. It's just kind of like a holdover of that I guess from my previous go life that I throw in the word test on there.

[00:02:27] I don't know why. It's like one of those silly things you do where you add the word list at the end of a variable that has a type list, right? Like, do you really need to do that? I don't know. Old habits die hard. We got one more question.

[00:02:37]
>> Is only the macro test irrelevant?
>> You mean this?
>> The pound bracket?
>> Yes. So yes, that is the thing that identifies this function is something that should be ran when you do a test. I don't know what happens underneath the hood when you do this, as you can see you can't even look at what is its compiler built in.

[00:03:01] Macros are very impressive, but they're also very hard to read sometimes, and so I don't know exactly what happens it just does what it's supposed to do and I'm very happy about that. All right, we got one more question
>> Yeah, so we mentioned having the tests in file.

[00:03:19] That seems like a design choice from the creators of Rust. What do you think the trade-offs are of having an end file versus another language or most other language which is where it's in a separate file and maybe even a different directory?
>> Yeah, so I feel I've mentioned it or at least alluded to it.

[00:03:34] One, I think file size is a great call out which is that sometimes these things can become unwieldy large. But two, I think we're really, I find it dangerous is the fact that so if you look right here, present working directory, we don't export this, right? No one can use it.

[00:03:49] It's not public. But down here, I can do pwd equals get present working directory and I can literally just bring it in, right? I can test internals that may or may not. How do you feel about that? Is it really a good idea? That's more of a testing debate, than anything else.

[00:04:08] Some people don't believe you should write tests at all, some people believe you should only write public interface test, some people believe you can test whatever you want. I'm on the public interface train that's where I've landed, so yeah. I don't like that about Rust is that you can do that.

[00:04:22] I would like to I mean, personally I'm I would just like that not to be an option, but I'm sure there's a good reason there's always a test that does exist. That's why if only I could just reach in and test this one thing because it's very important, I don't want it to be screwed up.

[00:04:36] I totally get that and I wouldn't argue with it, right? Yeah, so I can think of like RTP header parsing, right? To be able to do header parsing, you speak to any of these things. I'm sure there's a bunch of private functions you don't need to know about.

[00:04:49] But you also don't want to have to construct a stream of data coming in, just to test it so and you don't wanna export it as public. I'm sure there's good reasons to have that type of stuff existing. All right, so there we go. We finished really the section that part 2 of the four parts of our building of a CLI application, so it's time to move on to the greatest part of it which is the actual meat and potatoes.

[00:05:13] All right, so at least that's how I feel, right? It's time to do some real programming. This is where we're at, where we're gonna have to program these three operations, print, add, and remove.