Rust Programming Language RustFest Zürich 2017, 5 Nov 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: RustFest Zürich 2017 - Testing strategies and pattern for efficient TDD in Rust by Thomas Wickham

Description

Test-Driven Development is a systematic method to develop robust and self-documented software by incremental steps. To TDD in Rust, there will be 2 great obstacles. First, testing infrastructure will be harder to build as Rust lacks reflection, introspection, and casting. Furthermore it is known for its compiler strictness, making incremental development harder. This talk is aimed at applying the TDD method successfully. We will see the methodology by the book, some pitfalls, and how to avoid them with some Rust patterns and strategies that will help you ship at all time with great confidence.

About Thomas Wickham:
Hey I’m Thomas, consultant by day, and open-source coder by night. I work at OCTO Technology, a consulting firm specialized in Agile development and Software Craftmanship. I am passionate about empowering people in their daily lives and helping them undertaking their Why.

A

Thank you. Everyone today we're talking about didi who know what CD please raise your hands. Okay, almost everyone's good, keep your hand raised if you use TDD, okay and would seriously TDD for his walk ratio. Okay, thanks so I rock, with worst for three years and half of that time, without didi until it changed. Who are right. First, that's what I want to share I would be happy it's my goal. If, at the end of this talk, you would like to try to didi or try again for the project.

A

I will show you a way that works for me and I. Think it's efficient, so a bit about me by nighttime I do open source not like the big guys before me and after me, just a little. You can find me at Twitter on github at Mac week and shoot me a mail I, take all feedbacks at sweat well and by day I'm, a consultant I took to technology, which is a sub concert on film specialize in so far craftsmanship. We like two or three hundreds in Paris and like 14 rosanna.

A

So it's a little Chi Minh stress a good news.

A

A

So we're really passionate about quality code on software. Craftsmanship I took two and we wrote wait paper about that. So there is a part about Gd and my torque is I have to say inspired from this book, so it was more like Tech, leading maintaining quality and reducing burg. In the long run, this book have free and I will give them away or if you want at the end of its torque the things. Oh, it's it's fresh yeah and you is a Google form. When you can ask to a translation for translation.

A

Translation will be not free but like 2000 I, don't think I think something like that. So just click the link say yeah I want that I want one on. We will notify you when it's not rated yeah online check them out for no speeches not approve rates, but I will miss them public everything as they are written in the speakers. Not so it's self containing with reference link to what I'm saying yes, I, think so.

A

Means test drive on developments. Everyone know that is good. When we say tests, there is free kinds of tests. There is unit testing integration, testing and functional testing. I won't speak about the letter to I'm only speaking about unity thing here, because when we do TDD it's more unit tests that we want a question I got asks. A lot from my clients is.

A

Why do you test first? Its range I tend to do my work first and check later and that's a good question personally. I have five reason why yes, test! First, the first set: it's simply either when you write your code is then you write your tests, it's kind of fuzzy, you don't know how many tests do I do for this kind of God, where, where do I put seeds, although I name them it's how to write? It's really much easier to just do the test. First, that, yes, this is behavior I want to test.

A

This is what I want to do. I write the test and I do the rest. This is my opinion again. Another reason is, you won't test the intent when I said I want to test this behavior. You want to test the logic. You don't want to taste the same tag, so you don't want to take specific implementation. You want to test construction of your of your code. Your code is here to to to add value to someone, and this is intense.

A

You can also say that testing first helps in your design because you have not brought any code. Yet you are just calling your function. You say what will be its name? What parameters does it takes? How does it fits in your whole system? As we didn't float any code? We can change it as we want. So it's really easy to design things when we don't have code actually I'm, not particularly good programmer, usually I. Think yeah I understood that let's go, let's do that and then it doesn't work.

A

This helped me to challenge my understanding of the system, because, when I have to write a test on use my function and use the other parts of the codes that use what I want to test I can see that any one thing is it's not credible. I can do things like that, so when I test first I better understand and as some better, what I am doing final thing is my boss is happy, because this is a specification we are written on. You can go when you're later on CA.

A

This is this behavior of a specific bug. This is whole. It should be be taken care of by signification. That's that's really uncool when Wendy, when you have to come back later on the code. So this first reason it's easier I want to tell the intent of what I'm doing and not the code. It says in the implementation it has my design each Anna German does something on it's an executive specification very useful. Maybe you say yeah it's good, but what's your return on the investment or on investment?

A

Sorry, it seems like people have written about that, so I made links at the end of the talks that you can see later on maybe share. If you need to argue and that's all about TDD know how does it work, what I will show you know it's something that I do because it works for me, there's many things that don't work and I won't speak about that you can miss a step mystic in a cycle.

A

So when I speak about cycles, this is red, green refactor, the three steps of TD and we cycle between them in a tight feedback loop. The idea is to make micro step. So the grant is a red faz. Is you write a test? So you have to ask yourself: what do we want to test? What do I do next that I want to go forward? This is the first step of the cycle, so this is the one Wade will drive your cycle. We will see later about the next step.

A

The next test you so you watch your test. It's a dumb test and Emily and you make it pass in a dumb way. That's easy! You just see what the assertion is. You make it pass in the decibel way. The addition of right tests make it less and less dams on more non-smart, and then you take a step back. You recommend College say: oh, what can I every factor in my god? This is a refactoring step. You don't have to overdo it because you'll do it again.

A

The next cycle, that's very comforting, so you cycle back again and again, I'm again with either set visitor increments.

A

So when I said who, in the red step, you're driving your cycle- and you have to choose your next step- and how do you choose your next step, you have to think about something small that you can do fast, that you can quickly pass like Nick. You go forward on most important at all that you don't already have code, it's not so easy, it's a muscle train. So we will do a quick example.

A

Very simple, let's say I want to implement. I know a divisor and I want to so I want to make the divide function. It's very easy! It's only to show the methodology. So if you want to do a function and we want you to make function, just call it in your test, it doesn't exist. That's not bad, because when you do that, you have to think about.

A

Where do I put my function or do I name it. That's good start. So you have probably the zero innovation new function associated item MD right, maybe it's divisor I, don't know the tunnel sub-code. The green step is very easy. You just declare the function with a signature and maybe filling the Bronx, so it passes great, there's no sin to refactor. You can moving on and then we want our function to do something. So what's the is a thing we can do that we don't do we don't do anything we can put.

A

You know tests here, I'm a division by zero, because this is an error case. Zero case actually is quite simple: I only love to put an arrow in the rectum, but look what did we do just there?

A

We met a call where we choose parameters on what kind of return will be them here is a result and then I had adapt. My signature choose my type so here it's you, 42 could be your size and no depends on on your choice. um It's a little advance, but first time we say what would be in a function. How do I name it wait, wait, wait! It's a second time is what will be the signature, its I pay.

A

I will I want to use and you can see I didn't complete with the types of the results as it's just unit types, because yeah we can make tests later to assert that on specify that then to make the test pass. I also have to change my first test. That's not bad! So many micro steps micro advance again, there's no sin to refactor um you going on going on. Then you can divide by 1 and divide by truth and say: okay I know whom to use my function. What does it right?

A

Maybe I can make nan plus infinity minus infinity, plus zero means zero. You made all the little steps and then you are key and then your code walks on it's fully specified. Let's vary needs I like to do it so next step. The next test. Simply a muscle to train. That's the odd thing about GED. You can just enumerate behavior, we use case which are just variants just simply the same, and so it won't go forward or you can just go, make a step up too big.

A

Then your feedback loop is too large. You are deep in your code to make your test pass, but your test is too weak, just cut it in little pieces, so you have to slow down such an odd thing. But when you slow down you just look at the details. You take your time to do things right and so that you don't have to look back.

A

You can advance this CD way and what's nice with rest, is that you already have cargo tests and you don't need anything to test your function, so it asserts the is a good test for now you can start no, it's pretty easy.

A

So, let's say about general tips and remarks in TDD in rests. There's a new, it's obvious yeah rest doesn't like news, is performing odds with optional results, but also Russ is the hard to make it compile. You have ready to to prove to your compiler. That's it works only for the nominal case, the right case for all the error branches. You can just clone your sets. You can just make hot coded error status, it's very easy to under the error case. So you don't add. No, we have ok on error.

A

We have some unknown and known are very easy to just handle. So you just begin to under the error cases on your code. It begins stronger because you just do all the error and then, when you have done all 0, so no mean it is very easy to do code.

A

Maybe you know a road chain which is like quicker or plus plus I, like this quite a lot, especially the Bailey micro. So you can just deal with a quick string and later when you want to test zero later on, you can put a test on put your error. Kinda con, that's all very nice, very easy yeah.

A

When you do TDD, you don't have a lot lots of tests. So when I have like hundreds line of code for two thousand lines of tests, which is a lot but classic it's art, navigates in the file, so I tend to split the friendship or the module, which is will be like tasks and task underscore test where all the tests will be in terms of visibility in the crates. That's not tip-top, but it works.

A

It's was fine, and so you can have a split with two fives I, like that integration testing is in the test directory as a advice in the cargo guide and the this functional testing ham, which can put in your documentation on examples directory. So when you go go test, it will test with documentation examples. It would test the examples directory. You know that show the things that you won't show to user so thing or you want to design your API.

A

You can just put it in the test, an examples that will be tested. It's very handy, if you know wgg, you can do that with an example. I, like that, a lot so.

A

If you have ever done Ruby you have a spec where we tend to use describe.

A

For your type hierarchy you might describe your class, then describe your function, then specify your context with given cases I talk to repeat the same pattern in rest.

A

So when I do cargo tests, the arrow is more readable and then you can collapse all parts of the code and directly go where you want to go so here you have I think help you have your module, which is just a struct I want to test and resolve include, as name on Eastern plaited functions of hystrix in the inside this module, which which has the name of the function. I just put the test, which describes a function just a way to group your test, so you don't, you can easily navigate between them.

A

There's a lot of them. Maybe you have noticed this view. Super :, :, star, I, won't explain it in detail. Also. This made it change in the future with economic initiative, but it permits to use this in all the modules which are included and then publish them to the chain module. So you just do your pub use as a route and all the inside module will have the same use. It's like you're dry for imports.

A

Picking up dry. Please do repeat yourself, you know tests. We just have seen some talks about macros. There are not most readable things ever arose and even less with at all. When you test fail, you don't want to press time to decipher what you just rolled when you're latter. We want to just see the test. You want a good bug report. Where is there is a clear arrow, a clear path to this arrow and actually what this is?

A

What I expected- and this is what I got on this business match- macros, don't tend to give us that also set up functions and children functions. Usually don't give that also just do it simply. You have a function. Your test function. You have the orange part to act when you do the thing the assert, when you take the thing you must not test too many thing. You must not do too many things there are range. This is a little test. Keep it simple is keep it readable on most important level.

A

A failing test should be a complete, an explicit bug, report. Think of that when you're white row test, if the test fail, is it enough for me to debug in my code.

A

A

Speaking of setup of cheerin function, usually now in rusts we don't have max, we don't have tabs, we don't have introspection at one time. We don't have kind of this kind of things, so setup on children is strictly limited to putting similar turns filling the databases or creating files in the first system. This is not unit test. This is integration. Testing. Some time is fine, but most probably you don't need it and most probably this is your unit tests, don't need it and you can be reduced to the scope of what you're testing.

A

This is really the out part.

A

If you want God constructed his Google Form, like I, said I work at octo technology. If you're interested in Suffolk admin ships, you can shoot me a mail I'm Thomas we come walking Swiss with Ian for Joseph, we'll be happy to answer a question. I know that you want to eat so I make it quick, and this is a return to the end of the talk.

A

Tdd is about self-improvement. You know that show design is not perfect. You know that you do don't underlies the cases, but you know where you didn't endure a killer disease and where design is not good, and you know where is good on a weight on those cases. This is why a like TDD, which is why I tend to use TDD whenever I can every day may work. Thank you. Everyone.

B

Thank You Thomas. We have a few more minutes for questions. A.

C

Short question: how do you deal with code that does some kind of I are in a TDD fashion? Excuse me.

A

A much understood.

C

How do you deal with codes it does? Some I are like input/output like, for example, communicating with zookeeper, or something like that. How do you test code like that using test-driven development.

A

So let me reform, let you question you are saying: can my test call other external dependencies.

C

Yes or in general, doing any kind of I/o, basically yeah.

A

I okay so I, so sometimes you don't have any choice but I Oh usually is integration testing. If you can abstract from I/o that's best.

A

There is a the back shade that FM podcasts, which is very nice with Shannon Griffin. We spoke sometimes about this problem with Astra as free API on stripe. Api, where you can't cope them because it will create files or make payments.

A

You say: yeah I, don't have any choice. I and I have to mock them, but you can't mock universe. So what you do is generosity on you. You make it on plate of your of your function with a step thing inside. That's not good.

A

There is a way of TD T, which is named with a mock East Philly D, which is that load. But universe is harder to do so. I won't recommend you to use mock for IO and I recommend you to give your stage to a function. This function return another state and the IO kind is supported extracted unnoticed. It.

B

Okay, we have another question over there.

A

So my keys off.

D

A

Keys off okay,.

D

Oh yeah now I, sorry, okay, so my question is kind of swimming out I'm wondering if you've ever done any integration testing with Russ, because for me that really was always kind of annoying because you have other types and so on and really what you just want to write, especially for like a Web API is just like look at this status code, but you end up having to build tracing objects and so on yeah. Maybe is there way to do that with other languages like? Maybe you could script it in Python?

D

Have you ever considered that.

A

Could you shot a new question a bit yeah.

D

Okay, can you integration test using other languages? Are there smart ways to do that with rust, like you want to yeah.

A

By definition, integration testing integrate without thing which can be Python, which tend to be in node. We can be another thing: the risk there is that when you do coupling like that, you have to be very clear of what our user assumption of the other system, for example, maybe the Python you are calling is not the same version or are the same sister system dependencies and so which can pass in a system won't.

A

This is the risk with integration testing. Usually it's quite fragile because it works here, but not there. Does it really answer your question.

D

I was also asking like in a technical way, catching you rust errors and so on actually displaying them other ways to have test Suites that don't work, for example, if you're using like web frameworks and so on, I, don't think they exists. Anything for that yet, but I'm asking, if you do know about anything.

A

If I have made integration testing with race.

D

A

Question sorry: okay, that's.

D

All right, okay,.

A

E

Hi I was wondering when you, when you're doing test-driven development, do you have to turn off any real-time linting, because I know if I start mentioning functions that don't exist yet. My editor just gets full of angry red text.

E

So yeah, so do you? Do you use runtime linting? Do you get real-time linting in your.

A

E

Or do you have to disable it, but.

A

Yes, of course, you should do anything. Everything is very good. Yeah.

A

Yeah, no I don't see the issue here. Actually it's right, yeah.

C

B

A

Your tests, the feedback group, is quite short, the lynching helps you by giving your arrows, so you just okay. This is the first hero. Then there is an X and there is a next and you go for one like that. Anything is not an issue here. It's just a when it's a to you, it's not the right type. You have to decide if the type you made is a signature is not so good. If the type you made in your test is not good, it's only yeah.

F

A

It's a decision to take what we do: okay, okay,.

B

B

Okay, well, my question: over there you just walk off the stairs.

G

Okay, yeah cutting corners by leaving at a parameter, or you know, mocking module imports or stuff like that. Your rusty is a lot more fussy and well let you do stuff like that. Do you find that more difficult to write unit tests in rust, away.

A

From what well.

G

It's more difficult to write when difficult.

A

I come from the Ruby ball, but I have also done a lot of gyroscope testing in Ruby and JavaScript. Both it's far more easier to go forward to what I want and then walk out the arils and you you really forget. He rolls in roasts, as the arrow is easier to to UM dull I. Just do all 0, ok, I can think of and then I have references, I have basic type system and the nominal cause far easier to analysis. Difficult. It's you invest. You do your flow of salt about that.

A

Another thing: difficulties like don't choose reference where you're, not sure you want to reference across the refactoring can be quite Russell.

A

Lob's refactoring roasts can be very painful because you have to juggle between the fives and like this with module or directory or file, so you switching between them until you're happy.

A

This is a lot of changes compared to JavaScript or Java, where you can just extract method and play with that. No.

B

Ok well for more question over here, so.

F

In production, courage if I see repetition so I'm here. Thank you in my production code, if I see repetition, I refactor it away and don't repeat yourself, it's really important. What is it that's different about test code? That means that you think that repetition is good.

A

Excuse me, could you tell me you you.

F

Said that dry is not applicable for test code, and that surprises me, yeah.

A

F

A

Some more explain: Mary term, oh okay, when I first did TDD in rust. I saw a lot of factorization opportunities in my test, score, actually kind of always the same music everywhere, so you can make macro for that. You can make a lot of lots of macro, but there you introduced coupling between different parts of tests similar, but don't do the same thing and this coupling also blew your arrows. So it's not like you come to this. You can do this and sometimes it's fine. It's just that! You don't want to spend half an hour.

A

Just understand you test on what good, but you just want to see your tests and read it and say: okay, this is zero. This is what I want Fiske. Maybe you have macros in your code. Not your tests and the tests, which are not don't use macro, will be really easier to read, understand what went wrong in the macro. This is the difference for me. So.

F

Many macro instead of the problem.

A

Yes, I think macro as a main program, but Stubbs with generosity. So if you want to stop something in rust, you have to put your function statement of tests. You have to complete it so another common trait between what you want to use on your step, and this introduces a lot of visual noise. So maybe you are just reading the code and you have template everywhere and why do I have time plate? I, don't choose this time plate in my code, it's an oval okay,.

F

B

You so, sadly, we're out of time for questions, but we covered a lot of things and thank you for this amazing talk. Thank you.