Unit testing: How to get your team started

No video

Unit testing: How to get your team started - FunFunFunction #2

Рет қаралды 75,478

Күн бұрын

💖 Support the show by becoming a Patreon
/ funfunfunction
The team I am in now writes unit tests. Unit tests is part how we work, and it’s been really good for us. However, in most teams I’ve worked in during my career that has not been the case. In those teams, most of us wanted to write unit tests, but then we didn’t. So what did my current unit-testing team do, that my other teams didn’t? That’s what this video is about.
"History's Worst Software Bugs" - Wired, November 2005
archive.wired.c...
Simplex/Complex lating word etymology from the superb "simple made easy" talk by Rich Hickey, which is mandatory watching for all programmers:
• Rails Conf 2012 Keynot...
💛 Follow on Twitch and support by becoming a Subscriber
We record the show live Mondays 7 AM PT
/ funfunfunction
💛 Fun Fun Forum
Private discussion forum with other viewers in between shows. www.funfunforu.... Available to patron members, become one at / funfunfunction
💛 mpj on Twitter
/ mpjme
💛 Wallaby (Show sponsor)
Wallaby.js runs your JavaScript tests immediately as you type and displays execution results in your code editor. It is insanely fast, because it only executes tests affected by your code changes and runs tests in parallel. Let them know you came from us by using this link:
wallaby.funfunf...
💛 CircleCI (Show sponsor)
Robust and sleek Docker-based Continuous Integration as a service. I used CircleCI prior to them becoming a sponsor and I love that their free tier is powerful enough for small personal projects, even if they are private. Use this link when you sign up to let them know you came from here:
circleci.funfu...
💛 Quokka (Show sponsor)
Wonder how MPJ evaluates JavaScript inline his editor. Quokka is the answer - use this link when you buy to let them know you came from here:
quokka.funfunfu...
💛 FUN FUN FUNCTION
Since 2015, Fun Fun Function (FFF) is one of the longest running weekly KZfaq shows on programming 🏅 thanks to its consistency and quality reaching 200,000+ developers.
🤦‍♂️ The Failing Together concept is what makes FFF unique. Most coding content out there focus on step-by-step tutorials. We think tutorials are too far removed from what everyday development is like. Instead, FFF has created a completely new learning environment where we grow from failure, by solving problems while intensively interacting with a live audience.
Tutorials try to solve a problem. Failing Together makes you grow as a developer and coworker.
📹 Each show is recorded live on Twitch in a 2-hour livestream on Mondays. The host, assisted by the audience, is tasked to complete a programming challenge by an expert guest. Like in the real world, we often fail, and learn from it. This, of course, reflects what the audience identifies with, and is one of the most praised aspects of the show.
⏯ On Fridays, an edited version of the show is adapted for and published on KZfaq.
Content Topics revolve around: JavaScript, Functional Programming, Software Architecture, Quality Processes, Developer Career and Health, Team Collaboration, Software Development, Project Management

Пікірлер: 175

@maremp5 9 жыл бұрын

This is so awesome, I regret having only 1 like button :D You are staying true to the title, it's fun and I learned something new too. Excellent work, can't wait to see more.

@funfunfunction 9 жыл бұрын

+maremp5 Hey maremp! Thanks for your kind words, and thanks for holding me to my promise. :) More coming up!

@Musikur 3 жыл бұрын

Really good descriptions. Many people talk about unit testing, but not many people actually give practical examples of how you can add unit testing to complex projects

@this.too.shall_passs 9 жыл бұрын

"did you pause the video? of course you didn't!" LOL!

@tsunamio7750 7 жыл бұрын

You just helped me get a better understanding of the "Why the façad pattern is not a waist of time". I just had a lesson about patterns a few month ago, it's all good and nice but at times it is excellent to have real problems shown with the solution (pattern) that goes with it without starting to focuse directly on the pattern.

@LuisBurgosVarguez 9 жыл бұрын

Hi! I'm a software engineer student and i've been looking for a channel like this, you got funny, facts, theory and the most important: experience information. Your series of videos are awesome!! How about a video of design patterns applications in real scenarios?

@ManyouRisms 9 жыл бұрын

A day early!! Its like Christmas, but better.

@funfunfunction 9 жыл бұрын

+Jesse Preiner I'm releasing on 00:00GMT nowawdays, so it's technically still the same day, but 6 hours earlier than I did before :)

@artnikpro 8 жыл бұрын

Great video, as always! One important thing to mention, is that tests should (almost always) be written first, and then the actual code. This is how TDD concept was originally designed and this is how it makes it easier to develop. So that you wouldn't need to reload the browser page every time you made a change... and wait... and then visually test everything... When you have tests written you can just run a simple command in the console, and it will test each and every part of your code for you, and it will show exact places in your code where the bug may occur. Which means, you won't ever stuck again somewhere in the middle of development by thinking "what on Earth could possibly causing this bug, everything was working an hour ago...".

@CarlosAlfredoGarcellMelero 8 жыл бұрын

This show has helped me a lot getting off the ground with JS. Having been primarily a PHP developer, trying to migrate to JS (and make it my primary, go-to language for web development) has been a little bit of a hassle. ES5 and ES6, composition over inheritance, functional programming (and all of its inner concepts), async programming and so on...it's a lot! But it's been fun and realizing the real power of JS and achieving a level of comfort with it is something I'm bent on doing. Being a junior developer (and looking for decent employment) is hard, frustration abounds, but I'm certain the rewards down the road will make it all worth it. Thanks for this show Mathias!!

@funfunfunction 8 жыл бұрын

+Carlos Alfredo Garcell Melero So glad to be of service, Carlos! It's daunting at times, but stick with it. Tenacity and constant learning is what lies behind the illusion of "talent", so keep at.

@wayne7936 9 жыл бұрын

just getting my feet wet with programming. and this show is steering me in all the right directions. #makecoolshiteveryday

@kamdynjaxon8479 3 жыл бұрын

i realize it is kinda randomly asking but does anybody know of a good website to watch newly released series online ?

@carlalexander2028 3 жыл бұрын

@Kamdyn Jaxon Lately I have been using Flixzone. Just search on google for it =)

@JohnMichaelReed 8 жыл бұрын

Hi, I'm John. I study computer science at University. My school never taught me web development, only C, C++, Java, so I'm trying to cram all the information I need to write good web code. Right now I am learning Javascript and trying to learn TypeScript and Node and Express. Your tutorial about closures really helped me understand the output of the TypeScript compiler.

@BadPotat0 9 жыл бұрын

It's true that unit testing isn't easy to get accepted by a team, the choice of a test framework, abstract the data testing with use of mock, refactoring, etc, so many way to hit more walls. In any case, great wisdom in this video and nice little exercise!

@azizulkarim9636 8 жыл бұрын

This show is the best one so I have seen. Elegant, digestible and inspiring! Put lot of paid subscription based sites to shame. 👍

@Mitchicus94 9 жыл бұрын

Top quality video. This kickstarts people into so much potential with software engineering practices as well as general OOP practices. Well done

@eduardoverdeja9596 6 жыл бұрын

Motivating design patterns by explaining why it's difficult to write tests on legacy codebases and how to fix that was AWESOME. thanks mpj

@IsaacC20 6 жыл бұрын

@12:02 I realized that while the picture helps, having pseudocode helps clarify what the concept means while you're actually writing code. Martin Fowler did this in "Refactoring" but of course a book can't "hide" and "develop" diagrams the way a video can. The use of actual code (or pseudocode), provides a direct example for how to "separate" and "wrap" code much better than a purple oval with a mustache can. Just a thought.

@y1ink 4 жыл бұрын

Love your teaching style, it’s so good - teaching quite complex things in a fun and easier to understand way.

@herbertpimentel 8 жыл бұрын

loved that dramatic introduction

@dyllanusher1379 2 жыл бұрын

I can't wait to apply this at my current job. Thanks!

@hanvyj2 7 жыл бұрын

Also, unit testing at the beginning is often difficult to get behind because, in most of my projects, the early stages are often a bit experimental, the architecture is undefined and refactoring is almost a guarantee.

@rjorgenson 9 жыл бұрын

rocket surgery ... love it!

@funfunfunction 9 жыл бұрын

+Robert Jorgenson me too!

@MateuszZieja1 8 жыл бұрын

"It’s not rocket surgery™ is a trademark of Steve Krug." - Steve Krug "Don't make me think" - just saying ;-) What is your favourite Unit Testing tool / framework for javascript? As always great video!

@MehdiShojaei 8 жыл бұрын

Nice work! I know creating these videos is hard and time consuming. Thanks.

@afrowave 9 жыл бұрын

I am about to get into ES6 and I want to change my coding style to follow this: 1) Documentation 2) Unit Testing 3) Coding. Cold Turkey. No other way :-D. Thanks for the video, its allowed my to enjoy the process with FunFun. Keep up the good work.

@JimmyKeeseeJr 8 жыл бұрын

Great Video :) I'd also ad that converting Pseudocode that developers write in their meeting notes with product managers / state holders to unit tests first. I've found that if developers don't write their test first, they never will. It also addresses your 3rd issue as it gets them thinking in units before their start writing.

@richardlopes8810 8 жыл бұрын

Hey, I have been thinking on improving my programming skills by learning how to write unit tests. I found you and loved your way how to expose things! Cheers!

@sivaputrevu1854 6 жыл бұрын

It's the fun way learning stuff! My day starts with your video. Would love to hear much more from you!

@Soulixs 6 жыл бұрын

I love how you make it CS topics relevant to current events. Keep it up

@Joenr76 9 жыл бұрын

I've never succeeded in getting the whole team to do unit tests. And it only works when everyone is on board.

@philetaerus 7 жыл бұрын

Best discussion of unit testing i have ever seen. Keep up the great work.

@dominic23jones 7 жыл бұрын

Unit testing is like flossing - wise words!

@calkelpdiver 3 жыл бұрын

The medical device problems mentioned were similar to the Therac-25 Radiation Therapy machine in the early 1980's. That was a poorly tested system as well.

@RobertFerentz 9 жыл бұрын

Awesome video! I would love to see a video on the pros and cons of multiple abstraction layers.

@DonRichards 9 жыл бұрын

me too! I have a coworker that has abstracted their code to the point of unreadable.

@funfunfunction 9 жыл бұрын

+Robert Ferentz That is in excellent idea. I'll add it to the idea sheet.

@GaelDuPlessix 8 жыл бұрын

Hey @mpjme ! Thank you for your videos, they are purely awesome ! I'm just discovering your channel and will definitely take time to watch your videos ! :) I'm a junior programmer, working on a medium/large SPA with lots of "legacy" code. I'm committed to improve the quality of our code / workflow and I think your videos will help me in this task ! One question that keeps hitting me is this one: Everyday I learn new things about how my application could be improved. I would like to do composition over inheritance, I want to do unit tests, ... But every time I feel like the task is too large and I struggle at de-composing it to start implementing it in our team. For example, you're saying that to start unit testing, we need unit code. So to be able to unit-test, we first need unit code. But our code base is huge ! How can we unit-test our commits starting today if we have an non-unit existing code base ? Should we unit-test only the new components we write ? This breaks the "this rule is simple and unambiguous" because we start choosing when we have to unit-test and when we don't... So the question is: How do we start ? These concepts are great, we want them in our team but... how do we transition to this ?

@funfunfunction 8 жыл бұрын

+Gael Du Plessix I would recommend reading the book "Working with Legacy Code". If you haven't read it, it will change your life. But basically, it's the old "how do you eat an elephant? One bit at a time." If your code is in one big-ass unit, you cannot unit test it, so whenever you need to change some thing in the big thing, and you want to unit test it, you to refactor the code a bit so that that part of the logic is it's own unit - i.e. take a little bit out into it's own unit and make unit tests for that. There is a section in Legacy Code that is called "dependency breaking techniques" it's pretty sweet.

@GaelDuPlessix 8 жыл бұрын

+mpjme Cool, thx for the advice! I'll definitely check the book :)

@KrisRoadruck 8 жыл бұрын

You have a stuck pixel in your camera. I spent 5 minutes thinking it was my monitor before I moved the video around a bunch lol.

@VictorPotasso 8 жыл бұрын

that's not the only one :(

@igetom 6 жыл бұрын

Hi, I'm from the future and I did the exact same thing lol

@riceball100 7 жыл бұрын

ah this was useful to get me to understand how to write better unit testing, didn't think about the concept of braided code before, but this helped! thanks :-)

@benjgogan3587 5 жыл бұрын

this fella is gas, and knows his stuff. top watch

@ajgubi19 8 жыл бұрын

Love your videos man. I recommend them to starters all the time. Please never stop. :)

@filipeforattini 8 жыл бұрын

Amazing how simply you get straight to the point's core, I've just met your channel and I'm already a new subscriber! Keep rocket surgeryin' man! :D

@jeffontwo8636 8 жыл бұрын

Great stuff! I'm a JavaScript engineer working on expanding my horizons and becoming a senior engineer.

@tiredoftheliesalready 8 жыл бұрын

I honestly would love to get into unit testing. I have tried making some of our solutions more modular and have made suggestions for unit testing, but our shop is more waterfall than anything. We (well, management) only care about deliverables being produced at a certain rate and meeting deadlines, rather than caring about the overall integrity and testibiltiy of our code for the long term. Also, we currently have no senior developer with many more years of experience and wisdom, so it is a challenge to maintain appropriate learning or have mentorship.

@mynameisjoeo 8 жыл бұрын

The façade pattern saved my unit testing life. Thank you

@funfunfunction 8 жыл бұрын

+Joe O Mine too!

@djhaskin987 7 жыл бұрын

Pragmatic, realistic, fantastic. Thanks for all your work!

@sathyaprabhagirish3595 8 жыл бұрын

This video is pure Gold! "Unit Testing is Hard - emotinally! Unit Testing is like flossing your teeth." -LOL

@edvinsantonovs 8 жыл бұрын

I work with my team for a nearly 2 years, we haven't written a single line Unit test. It's really sad that no one really cares about it. Hopefully I will have a chance with a team who writes Unit tests in the future.

@nareshtank7430 7 жыл бұрын

All code is guilty, until proven innocent...great work!!!

@Mustackk 8 жыл бұрын

Hi Mattias, I'm really loving your videos. Having favoured computer science classes over software engineering classes in university, I feel like my knowledge of design patterns is a bit lacking. I'm always looking to learn more about those. This video helped me with that but I'd love to learn about more patterns that I can apply in my projects. I currently work in client-side Javascript so if you think there are patterns that are more relevant to that, please let me know what they are whether or not you make a video about them. By the way, my manager shared this video as a way to help us think more actively about unit testing and I think it worked.

@MattFarmerdotnet 8 жыл бұрын

+Mustackk Check out addyosmani.com/resources/essentialjsdesignpatterns/book/

@GaudyMarko 7 жыл бұрын

I'm a computer science graduate trying to prepare for an upcoming job interview, if I get the job I'd be responsible for writing on target, off target and hardware simulation unit tests.

@XIIIShade 5 жыл бұрын

15:50 those graphics made me hide my screen from unaware people behind my back

@secretwpn 7 жыл бұрын

Question about p.1: With a classic example of testless codebase - when you apply the rule "No commits without unit tests" - what exactly should be covered? Say I refactor somethign and end up with 10 files affected to some degree - should all the methods that contain modified lines be tested? Or every method in every file? What if 50% of those modifications were simple property renamings? Test those also? There is no twist in this question, I just really want to understand how to start covering large project with unit tests. Thanks!

@evolopterus 8 жыл бұрын

When I design functions to be independent, environment agnostic, robust units... I run into the need to add lots of input validation code. This often translates into "if" statements to make sure the input is of the correct type and range, or skip the processing and return an error (usually a null). On the other hand, I see this guard logic adds more weight and repetition to functions. I am not sure if functions should be simpler and assume their input is correct, and simply add the fault tolerance to the caller... or keep treating each function as obsessed with input validity.

@jessewlord 8 жыл бұрын

+Evan Noway (amivag) I have been using try catch to output useful error messages and reduce the need for this kind of logic inside of functions (essentially putting fault tolerance on the caller). Then your function can be separated from the error handling and have only logic that is relevant to the computation. I like this method because you can also unit test your error handling functions.

@anothermouth7077 2 жыл бұрын

Sometimes as a small time developer we loose the track of big picture, we may think our product is not much important and maybe our mistakes won't have much impact. We don't realize we are small cogs. As Uncle Bob once said day is not far when politicians will bring in laws to scrutinize software deleopment.

@makerbros5496 8 жыл бұрын

Great episode, however I believe that you described the proxy pattern you talked about facade.

@funfunfunction 8 жыл бұрын

No. A proxy maintains the same interface as what it's proxying. Facades hides the original interface and exposes a more simple one.

@AngusMcIntyre 7 жыл бұрын

thanks mpj. this is really great. I'm going to try and do a team session where we watch a funfunfunction video once per week. Also. I'm a c# .net developer and I want to write elegant, readable OO code.

@DanielRamBeats 8 жыл бұрын

"A huge F***KING brick wall."

@davi_singh 6 жыл бұрын

Why am i just finding this now... lol awesome video

@LoneWolf-wp9dn 4 жыл бұрын

Sometimes when i do a commit ill say "Hey at least it cant blow up"... other times i make a wide and obvious cross sign... that tends to make my fellow developers uneasy :)

@darrenking8941 7 жыл бұрын

Awesome vid, MPJ! Nice mixed metaphor too - not "rocket science" or "brain surgery", but "rocket surgery"! Imagine what that looks like! ;)

@hectixx 8 жыл бұрын

Would be nice to have a video showing some application of these patterns in JavaScript.

@uglypie182 8 жыл бұрын

Love these videos! I laughed pretty hard at the pause video thing.. :) How about doing a video on choosing frameworks/libraries?

@funfunfunction 8 жыл бұрын

Thanks! I have done that video.

@uglypie182 8 жыл бұрын

+mpjme Oh, just noticed. Thanks!

@maxeminem777 6 жыл бұрын

So much skill with the drawings :3

@JemDhali 7 жыл бұрын

Thank you.

@puraniksaket 7 жыл бұрын

Wow We practise always mocking objects and sometimes feel stupid mocking the dependencies and ending up creating stubbe dobjects. Facade can be an interesting thing, Thnx for that

@lucianosugiura 8 жыл бұрын

Just have watched all your channel... Found one video at quora and just kept watching all of them! Nice work! =D BTW I'm an iOS dev @ Kekanto @ Brazil, RoR and JS learner I'm beginning to research on functional (reactive) programming, so it'd be nice to see some videos/examples/experiences by you about it! Tks! =)

@Kirkland_Signature 8 жыл бұрын

Can you do a video or videos on thinking algorithmically in Javascript or Big O notation? I feel like that's a subject that's touched on rarely in JS tutorials but can really help programmers learn how to write efficient and performant code not just in JS but in virtually any language. I've found a few videos on it but it's pretty terse and difficult to know where to even begin. Thanks for the videos, they've been a huge help so far!

@funfunfunction 8 жыл бұрын

+Anthony Barsotti I largely find Big O to be a bit internet-penis-bullshit and dislike it, but it would indeed be a popular video. I need to find an angle that would make me feel like it. :)

@pedrocalaisguerra 8 жыл бұрын

Excellent!

@bg-rz7vd 8 жыл бұрын

this is awesome.. thanks

@MrCiDevant 8 жыл бұрын

+mpjme Perhaps a little bit stupid: In new teams I introduce Testing almost always with a Nyan-Cat reporter (The more tests the longer it flies) It seems to motivate people :) Also I think that testing is often very overcomplicated - I used to use big Frameworks like Karma / Mocha but nowadays Tape is enough for most tasks (and the tests are very portable) Finding a common vocabulary in a Team is very hard aswell. What is a Unit? Ist it a Function? An Angular Module? (the old naming problem: e2e? integration? regression? etc. etc.) I would like to hear your opinion about "Unit" Testing in Angular (or...well the way the advertise it - I think it is just horrible)

@funfunfunction 8 жыл бұрын

Nyan, that is great! It really takes the edge off things, I guess. The question about what a unit is - I really think that is something that the industry is bad at dealing with today. It can be done in many ways, so I think that defining the individual, testable unit is the most important thing that a framework should provide, yet all the popular ones fail to do just that. :( I don't like Angular at all so you won't find me doing any videos about it, except possibly ripping it apart, but seems like that has been done to death already.

@OmulNegru82 8 жыл бұрын

Very nice post...

@jesselisser 8 жыл бұрын

Thank you! Awesome vid..

@uzor3109 8 жыл бұрын

You've earned you a "subscriptionThing". Good job dude!

@Lordrainor 8 жыл бұрын

Loved the intro

@GfastGao 8 жыл бұрын

It's just another awesome one made by mj. I'm wondering, if it will be even cooler, if you add some very very very very short youtube tutorials talking about the same topic. For instance: Let others "commit" to you in the comments or through Email. And you try your best to "merge" them by linking these tutorials in you videos' Description later.

@BrettCoffin 9 жыл бұрын

Cool vid but probably the least fun... I think you should have added some dragons gnomes etc... When you talk about the Façade, do you see it as an Interface in Java for example ? I would love to see a video on Reactive Programming :)

@funfunfunction 9 жыл бұрын

+Brett Coffin The facade would be an interface in Java, yes.

@mickvangelderen3745 8 жыл бұрын

Hey +mpjme, thanks for creating these awesome videos. I'm thinking about putting your videos on the big screen during lunch ^^. Anyways, how would you go about testing the PaymentFacade? The PaymentFacade drawing looked a lot like what we started with.

@Samgato2008 8 жыл бұрын

I couldn't laugh more at 5:28! :)

@ThePreyBrigade 8 жыл бұрын

I like these videos.

@GfastGao 8 жыл бұрын

Error: at 13:54, protectionEligibilty should be protectionEligibility.

@VladAlive 9 жыл бұрын

"complex"-icating the code is what most programmers are doing their whole life. it is not a surprise, refactoring tightly coupled code into smaller units is not that fun. it seems a good idea to write unit tests to most of developers, though still something prevents them from starting doing it on a daily basis. it's not that hard to start in terms of knowledge or skills, most testing frameworks cover all useful cases in their docs. looks like the problem is in our attitude, emotionally hard to start.

@hal1900 9 жыл бұрын

The first 2 minutes where the least "funfunfun" or all your videos! ;) Still, good point and great video again.

@thiago061290 8 жыл бұрын

Added to the favorites \o/

@anythingforweb 8 жыл бұрын

Great video, but I still don't get it. If I mock something to be a value, of course the test will pass my mock. I'd love to see a video like this with examples for newbies. Thanks!

@hairyshoulders5866 8 жыл бұрын

+Adrian Florescu Even I am a newbie, but I believe I can answer your question. If you mock a value and pass it to your unit test function, along with the expected value, your unit test will run the module being tested and compare the actual output to the expected output that you passed to your unit test. If they are the same, your unit test passes, otherwise it fails. A very simple and silly example would be a factorial function. You pass the value 5 (the mock value) and the expected output (120) to your unit test. It will run the factorial function against the mock value (5) and compare the output to 120. Now whenever you modify your factorial function, if there is a bug in it that is caused due to your modification, the unit test will catch it immediately because the actual and expected output will be different. Your test will detect if the factorial function works properly or not. Of course in real world programming, you will be unit testing modules with significant lines of code, with the possibility of many bugs. I could not think of a better example because as I said, I am a newbie. hope I helped.

@beto.aveiga 4 жыл бұрын

Units tests must be an agreement since the beginning and start as soon as possible. If you start a little later the code will not be ready to be decoupled and the effort will be so huge to embrace it that no one will accept unit testing. At this point probably you will only do functional testing, or integration testing, not unit testing.

@Apithia 8 жыл бұрын

Can you do a video about design patterns?

@errduende 8 жыл бұрын

+1 and talk about dependency injection and ioc in Javascript

@davidfischer9186 6 жыл бұрын

wow, great vlog!!!

@softwaredeveloper6791 8 жыл бұрын

Personally, I doubt that unit testing could reliably catch the software flaw mentioned in the beginning of the video. The doctors entered incorrect data. Sure, Multidata Systems could have fuzzed the system with many different types of incorrect data, but that's not unit testing, that's fault injection testing. Additionally, it's provable that testing all combinations of inputs and preconditions is not feasible, even for simple products. Defects that occur infrequently are difficult to find in testing. By the way, that "buggy" radiation therapy software functioned without event for 10 years, and only in 2001 was it found to contribute to problems. In conclusion, it's a good story, and unit testing is very important. However, the story is not really related to unit testing. How lazy were those physicians? The physicians were legally required to double-check the computer’s calculations by hand. But in all that time, didn't any of them performed those calculations and realise that the results of the system were different than those done by hand? They needed to raise the issue with the vendor who would then charge all the hospitals for new software updates. Instead, the physicians go to jail and the software company had to do the updates for free.

@jameschung9548 7 жыл бұрын

sounds like good music to code to

@jakubrpawlowski 6 жыл бұрын

Genious!

@AlexeyMenOfSteal 7 жыл бұрын

what do you think about FreeCodeCamp to learn programming?

@arifpambudi9459 7 жыл бұрын

What music did you use in 1:49 ?

@paulhammond8583 9 жыл бұрын

Hi Mattias - you talk about commits having to have unit tests - surely this wouldn't even be an issue if you're doing TDD? If you're doing TDD you'll always be coding to make a test go green or be refactoring to make the code prettier/easier to work with. I actually disagree with some of what you're asserting here. The problem with what you're doing is that by considering the code under test to be the "unit", you end up having to mock out collaborating objects. For example you mock out "Paything" because it's a collaborating object within OrderThing. This creates a problem - the problem is that your test code will now be tightly coupled to your implementation code. Your test knows too much - why should your test know that OrderThing uses a PayThing under the hood? Now if you come to refactor OrderThing at any point, you'll need to remember to update your tests too! Even worse, if you change something inside PayThing that means that OrderThing no longer works, this would not be picked up in your unit tests! In an ideal world, your tests should be used for refactoring. You shouldn't have to update your tests when you refactor your internal implementation. You may argue that Kent Beck originally told us that we need to focus on the unit in order to isolate the thing we wish to test. However, the mistake I believe a lot of people make here is that the unit is the code under test, or the object under question. If instead you treat the unit as the *behaviour* you wish to test - so the unit is the *test itself*, you find you don't need to use a mock under these circumstances. It means your tests are no longer tightly coupled to your implementation, you don't need to update your tests if you refactor your implementation code, and even better, if you change something inside PayThing that breaks the functionality in OrderThing, your unit tests will pick this error up! There's an excellent talk by Ian Cooper that changed my mind on this one. Ever since following his advice I've found I can use my tests to refactor brilliantly - the tests don't get in the way of refactoring - they actually aid it. I highly recommend you watch this video: vimeo.com/68375232 Cheers, Paul

@funfunfunction 9 жыл бұрын

+Paul Hammond Seems like a cool video, I'll add it to my watch list. Please note that this video is not at all about how to do unit testing in an ideal way, it is about about a pragmatic approach to get a team that has little or no experience with unit testing to get started.

@paulhammond8583 9 жыл бұрын

+mpjme Cool. I did disagree with that particular assertion, but I love your presenting style and enjoy your videos. Keep up the good work (be interested to know your thoughts on that Ian Cooper presentation too - it really made a huge difference to the way I write tests, and I've never looked back!).

@ayyappaaryan3121 7 жыл бұрын

can please make a good number of videos in jasmine & karma please

@xxysergiuyxx 8 жыл бұрын

that was aweaweawesome :D

@winterhell2002 6 жыл бұрын

Whats the point of the computer making the calculations if you have to double check by hand

@funfunfunction 6 жыл бұрын

Unit tests are not checking the computers calculations, they are checking that the changes you make to the software doesn't break any of the many earlier cases you (or your colleauges) have coded into it.

@dk0r51 8 жыл бұрын

06:40 Great video; terrible flossing analogy. --Floss more!

@beto.aveiga 4 жыл бұрын

That banana gave you one like today! :D

@Neppord 8 жыл бұрын

+mpjme nice. To bad that you use the word mock for things that imposes no asserts. That kind of thing usually confuses the bananas out of beginners, mmmm bananas. And also makes the video feel like it's from before 2007. Maybe a video on different types of test doubles would be a good idea? Keep up the good work!

@funfunfunction 8 жыл бұрын

I know that there are efforts to separate the concepts of doubles, stubs and mocks and fakes, but I've found no consistent agreement on the terminology. In the end, I just went for using mocks as a blanket term, as that seems like the way most people use the word.

@BalticWind 6 жыл бұрын

Cool )

@SteveHiemstraAKAspeg 8 жыл бұрын

Any suggestions for mocking ES6 imports?

@funfunfunction 8 жыл бұрын

+Steve Hiemstra Yes. Don't. Imports are not an injection mechanism, don't use them as such. In addition, it requires weird magic and is hard to manage. Instead, I just write functions with dependencies as arguments to a core function, so that I can inject mock objects into them in tests, and before providing the function to internal code I weld on the real object. Example: github.com/mpj/cannonville/blob/master/src/client/index.js "constructor" is the tested function and net is an external dependency.

@SteveHiemstraAKAspeg 8 жыл бұрын

+mpjme What do you call index.js? It looks like this is a prep area where you mixin your dependencies so that they can be consumed by your app in run.js. If you have lots of modules that need to be prepared like that, do you import, mix, and export all of them in index.js? Perhaps a good topic for a video ;)

@funfunfunction 8 жыл бұрын

I sometimes call it shell.js instead of index. One core and shell per module generally, but that is mostly because my modules only tend to export one thing, I dont have a strong opinion on that one. The important idea is to have a shell and tests that injects dependencies into the core. Super easy to mock and code that uses the module will never have to know.

@WilliamCerniuk 6 жыл бұрын

What ever they are paying you, it's not enough.

@MrEldari 8 жыл бұрын

Could you subtitle this video? I would like to translate it to portuguese.

@Davidlavieri 8 жыл бұрын

Is not that Dependency injection?

@funfunfunction 8 жыл бұрын

+David Lavieri it can be called that, but I don't like to use that term because I unfortunately find it to be very infested as a terminology. What many people associate with DI is huge meta-programming frameworks from the .NET and Java which is absolutely not something that I want to condone.

@errduende 8 жыл бұрын

+funfunfunction it could be a great video talking about DI, DI containers, IoC and theirs implementations in javascript. There are a lot of controversy around DI in javascript and perhaps you could clarify why it is needed or not in JS ;)