Victor Rentea - Unit Testing like a Pro: The Circle of Purity
Вставка
- Опубліковано 17 кві 2019
- Being able to focus on the fun creative part without any fear can make development very addictive. Extensive unit tests can buy you that! However, unit test code is still code, lots and lots of it, if done right. And it has to be maintained just like any other code.
Test code can be 3x times larger than the prod code, so if your tests are not maintainable they will end up slowing you down and causing you painful headaches, compilation errors and spurious failures. To avoid that, your unit tests should be significant; expressive; clean; DRY; non-overlapping; and blazing fast. They are hard to write. And they have principles you need to follow. Principles that will end up shaping the way you design your production code itself. And then it will be obvious: unit testing is all about balancing cost-benefit. It’s about maximizing the regression protection you get vs. the maintenance price you need to pay for those tests. It’s engineering.
Grab a black coffee and join this extract from Victor’s Pro Unit Testing training. You will learn about testing priorities, avoiding buggy tests, testing exceptions with JUnit 5, the shared @Before nexus, guidelines for breaking an unit test, and crafting splendid expressive failures. In the end, based on the difference between a Stub and a Mock you’ll get applicable advises that can make your code a lot more testable and easy to understand, isolating tough critical logic inside a ‘circle of purity’. All of that in an entertaining, dynamic and memorable session. - Наука та технологія
Nice. Unfortunately the microphone hasn't been tested first.
@Hugo Emmett curious what it did to your browser in that 20 mins ....
You all probably dont give a shit but does anybody know of a way to log back into an Instagram account..?
I stupidly forgot my login password. I would appreciate any tips you can give me!
@Blake Case Instablaster ;)
@Noel Brantley thanks for your reply. I got to the site on google and I'm trying it out atm.
I see it takes a while so I will get back to you later when my account password hopefully is recovered.
@Noel Brantley It worked and I actually got access to my account again. Im so happy:D
Thank you so much you really help me out!
Thanks a lot Victor, this according to me is one of the best talks on testing. It made me look at the test code in a whole new light. Salute!
One of the best talks on testing code. Kudos to you
best + most practical talk on unit testing, Kudos to the presentation Victor! Keep it up.
Love the energy!
Awesome talk, Victor!
I never cease to be amazed how often Tech conferences have technical issues with sound and video.
Cool presentation
Epic talk! Thank you!
Are the sliders available?
To not break the encapsulation one might use Whitebox library to directly access private methods.
Could you drop me a link please? Thanks!
@@vrentea For example this one self-learning-java-tutorial.blogspot.com/2017/07/whitebox-test-private-static-methods.html?m=1
Whitebox uses reflection under the hood to call private methods, or even to assign values to the private fields.
I am little confused about extracting a method out to create pure function at 55:38 , which is good for testing... But that will also mean that we have to make the method public? It may not be an API we want to expose!
As more easy to test is your code less fear in there. The point here is right, ur broking encapsulation but in order to improve testing. In this particular case maybe you should move this method to another class, because it's so complex that needs its own test, and if it need a new test for puse function, maybe need its isolated encapsulation
@@cehdmoy
Thanks for the reply. But I do not understand... Even after moving the method to other class we will need to make it public for testing, isn't it?
I have actually faced this problem before, where I had a choice of creating a mock object or making a private method public. I made the private method public for testing. But I still feel uneasy about it even after 2 months. :(
@@SourabhBhat I had been in same situation and I don't have an answer, but I do know that this situation is better than have some piece of code badly test in there.
@@cehdmoy Okay... Thank you
You can consider either package-protected access, or if that doesn't work, a popular convention is "creating internal packages, and documenting those packages as implementation-dependent and subject to change without warning or backwards compatibility." (kdgregory from StackOverflow). If everything falls, Guava has this Java annotation called "VisibleForTesting", which is not as clean, but an idea for last resort...
Quite a few can be solved with a more expressive/verbose framework like AssertJ (expecting throws, collection test failure legibility etc). Love your style Victor!
where can I get the rubber pig?
Better title: How to build a test suite so large, it has its own gravity
good stuff. shared it with the rest of my team. thank you for giving this talk. it was a lil hard to understand, maybe in the future work on English enunciation. but other than that, good stuff.
Point taken. (disclaimer: I had to google what enunciation means 😂). It was the first time I ever gave it, so indeed, i wasn't focusing on the phonetics at all.
I could understand on double speed but I'm native speaker
Good stuff. Still, I can't agree on using those BDD-style ".feature files", IMO they're just a waste of developer time.
If they are imposed upon them, indeed. But if they choose to do it to minimize the risk of misunderstanding, they are quite valuable IMHO.
@@vrentea I'm sure it makes sense in certain contexts. In my experience though, developers don't get any benefit from writing tests in plain english as they already speak "code", and business guys don't want to read those tests anyway (or any code, for the matter) as they can just ask the developer. Also, in agile environments, I'm not sure it matters much what was put in those tests when business requirements change.
Whats up with audio ?
for a moment I thought it was Mike Tython talking
?
Relax man, it's bad for your heart. Good content though.
No, extremely basic and sometimes even wrong and misleading.
For non-english speakers this video is impossible
It's pity when an exciting and important topic is described in a clown manner.
I can't watch speakers that sound like over the top evangelists on meth. I much rather watch a talk by Uncle Bob and leave pleasantly surprised and enlightened.
I appreciate funny presentations when the delivered content is still professional. Fun keeps us motivated to keep listening.
Well, in my experience, it's a lot easier to reach the majority using analogies, metaphors and jokes.
But as usual, it depends on the audience.
@@vrentea true but you were objectively too loud for the degree of seriousness the subject has. This is not something you should shout to people to make them understand.
Tell us you're insufferable without saying you're insufferable @fedord7602
Basic content, and he's not funny contrary to what he must be thinking.
Poor audio hinders understanding in addition to his strong accent (btw I'm not native English speaker either maybe that's why I find it hard to understand all the words) and the automatic closed captions are in... Dutch! (not his fault I guess although Devoxx could have fixed that)
Yeah the lack of auto-generated English captions is a letdown... I would rather auto-translate from English to Dutch instead of the other way around.
I will probably repeat this talk in the future.
Hello friends of DEVOXX.
it is possible some way to consider in your events. that the translations are more understandable into Spanish. the ayoria of the videos, by the way excellent can not be fully understood, due to the poor translation of the Dutch (by default) -- into Spanish. Is there any method or way to have a better translation?
The event is coming on March 22, 2022 and we would like to have a better translation friends, sorry for the inconvenience of people on this other side of the Spanish world.
Thank you and may you be well