I have watched you for quite some time now. You have just gave me the biggest boost with something so simple providing me with a solution to a problem i am currently faced with. This video was nothing but love.
We use the same pattern for large projects and it works great. Just keep in mind that it works well for services (global states, external APIs, db etc...). Use require and stub with rewire or mockery if necesseray for stateless librairies (pure functions). The best pratice is to keep services the tinyest possible and use pure libs over it to manipulate global states. The console service would be better by requiring the log function and pass to it the console object when logging, by example.
Very cool project and great video as usual :) I really liked not using require directly (which would have been a lot more harder to mock in the tests), but generally I would prefer to use pure dependency injection (passing every dependency as separate parameter) rather than a single service container object in a "service-locator" fashion. Of course this really makes sense only for bigger applications and DIC/Service locator was not the goal of the video, but maybe this topic can be an hint for one of the next videos. Congrats again for your amazing work and keep pushing great stuff :)
(Video Idea!) I'm a self taught developer, and it wasn't until I got to college that I learned about the importance of pseudocode, or what pseudocode is really. It seems like something everybody knows, but most books new programmers read focus on the language syntax and features, not how to organize and plan their code.
Hi Mattias, I'm loving the videos! If you are looking for ideas for future lessons, how about the use of OAUTH2 in web apps? Cheers :-)
8 років тому
Trying to get into unit testing, finding your episodes about testing really useful. What are some must see articles, talks to read or watch about testing?
Thank you so much for this episode! Can you provide some more sophisticated example of this pattern (core-shell)? What if my core uses lodash as a dependency? Should I add it to services or just require it in core.js? I find this pattern really appealing and would like to deepen my knowledge, I already watched Gary Bernhardt's talk 'Boundaries'. Thanks a lot!
+sdsdsdfsdf I would just require it. The reason we inject, say, a database or payment connection, but require libraries like lodash, is that lodash doesn't have state and/or side effects. When you call some lodash function with a value, you always get the same value out, because lodash is stateless. A database connection is different from that - when you call a database it might give different results for the exact same call based on what the state the database is in - this means that the database state is basically an input to your test, so you need to mock it. It is a dependency with state hidden somewhere else than the input parameters to the function.
The boundaries talk was great. So you have the shell and inside is the core. In another project, could core very well have requirements? Like from the talk, where he had three shells, each with it's own core? The shell refers to external to the core code right?
How do you scale this pattern over large projects with multiple modules? It seems like you would have to write shells for each module (which means writing two files for each module) or exporting a function that takes dependencies as arguments from every module (which requires the parent module know the child's dependencies).
+James Meyers Yeah, it's two files for each module, but that is no problem at all. Right now, I have a pattern where I have a directory for every module. So, imagine a directory called "waffle" or whatever your module is named, that contains index.js, core.js and test.js. index.is basically the same as shell.js in the example linked in the video description, i.e. the thing that welds on the "real" dependencies on the core before passing it on to parent functions. test.js is the unit tests for the core, and it tests it by creating and injecting fake versions of whatever index.js is sending in. This way, parent modules just have to require('./waffle'). They don't need to know the dependencies, that's handled by waffle. I have a project with tons of modules right now and it's working great so far.
I once was a huge fan of mocking in general. Now I don't. Problem is that if something in the underlying implementation of e. G. fs or the hue-api changes, your tests will not fail. That might be ok for your little project but for large projects with many modules in place that is horrible. I only mock where it's absolutely not possible to test it with real implementation. The way I do it mostly than is to monkey-patch as deep a possible. Your implementation uses a pattern just for the sake of easy testability. I found that odd. In your very case I would just change the nupnpSearch function of the hue module by monkey-patching it.
+Stephan Hoyer Stephan, I know the allure of throwing unit tests out for integration tests. It seems so attractive. The problem you describe with underlying API changes is truth, but your integration tests approach has big downsides as well. It's just how the universe works, there are no perfect tools. If you give up on a girl just because you realize she has a bad habit, you'll never find true love. :) Joking aside - we use both kinds of tests at spotify extensively, because both are different. I started writing about it here but realized that the answer turned into a video script. :) Until I decide to make a video about it, the the tl;dr is: that the tests you describe are what we call integration tests, and used to test the "vertical" functionality of the app, while unit tests are focus on testing "horizontally". They both have different strengths and you cannot replace one with the other, you must have them both.
Love your videos about testing! So, I'm writing tests for a react component that takes a date as a prop (a moment object). I'm then testing if my component renders the correct number of days depending on the month. Is this a codes mell since it will break my tests if moment introduces a bug? If so, how does one handle it? Do we mock moment, or do we extract the moment-logic out of the react component? Maybe both? PS When I say mocking, i mean mocking the behaviour if the moment functions used by the component (in this case getDaysInMonth). Best regards, Daniel
+gom tv it's a matter of taste. I would do it the way you do. I generally only mock things if they are stuff with side effects (such as calling the database or getting the time from the clock) or if it's external components that are complicated and I just don't want to think about it (maybe a order manager interacting with a payment system, then I might mock the entire payment system).
In Atom or Sublime Text, make a text selection and press CMD+D as many times as you need (or keep it pressed). Not sure if it's a native feature of if it's added via Emmet.
+Sagi Avinash Varma this could be referred to as injection, yes. I don't like to use the term dependency injection as a lot of people associate it with nuclear power plant sized dependency injection frameworks like the one in Angular. This is just passing dependencies as arguments.
+Austin Wulf It's okay, I guess. I prefer tape because there is less magic involved. I always have a hard time getting mocha to play nicely with anything but mocha.
I have watched you for quite some time now. You have just gave me the biggest boost with something so simple providing me with a solution to a problem i am currently faced with. This video was nothing but love.
We use the same pattern for large projects and it works great. Just keep in mind that it works well for services (global states, external APIs, db etc...). Use require and stub with rewire or mockery if necesseray for stateless librairies (pure functions). The best pratice is to keep services the tinyest possible and use pure libs over it to manipulate global states. The console service would be better by requiring the log function and pass to it the console object when logging, by example.
The idea of core an shell is really helpful!
Very cool project and great video as usual :)
I really liked not using require directly (which would have been a lot more harder to mock in the tests), but generally I would prefer to use pure dependency injection (passing every dependency as separate parameter) rather than a single service container object in a "service-locator" fashion.
Of course this really makes sense only for bigger applications and DIC/Service locator was not the goal of the video, but maybe this topic can be an hint for one of the next videos.
Congrats again for your amazing work and keep pushing great stuff :)
i learned and learn a whole lot of your videos - keep it up! and thanks...
Oh man your github picture too funny!
I love the Swedish pronunciation of "mocha" :)
(Video Idea!) I'm a self taught developer, and it wasn't until I got to college that I learned about the importance of pseudocode, or what pseudocode is really. It seems like something everybody knows, but most books new programmers read focus on the language syntax and features, not how to organize and plan their code.
+Tyler Waite wow , that's a pretty cool idea! I'll add it to the doc.
That d20 =D.. Great vid =)
The jacket and necklace makes you look kinda like a wizard.
Hi Mattias, I'm loving the videos! If you are looking for ideas for future lessons, how about the use of OAUTH2 in web apps?
Cheers :-)
Trying to get into unit testing, finding your episodes about testing really useful.
What are some must see articles, talks to read or watch about testing?
This is in C# but it's a very good introduction to unit testing: www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
Thanks will check it out!
Great content
I tried running kill-lights but not found. Had to run node src/cli.js to run it.
Thank you so much for this episode!
Can you provide some more sophisticated example of this pattern (core-shell)? What if my core uses lodash as a dependency? Should I add it to services or just require it in core.js?
I find this pattern really appealing and would like to deepen my knowledge, I already watched Gary Bernhardt's talk 'Boundaries'. Thanks a lot!
+sdsdsdfsdf I would just require it. The reason we inject, say, a database or payment connection, but require libraries like lodash, is that lodash doesn't have state and/or side effects. When you call some lodash function with a value, you always get the same value out, because lodash is stateless. A database connection is different from that - when you call a database it might give different results for the exact same call based on what the state the database is in - this means that the database state is basically an input to your test, so you need to mock it. It is a dependency with state hidden somewhere else than the input parameters to the function.
The boundaries talk was great. So you have the shell and inside is the core. In another project, could core very well have requirements? Like from the talk, where he had three shells, each with it's own core? The shell refers to external to the core code right?
How do you scale this pattern over large projects with multiple modules? It seems like you would have to write shells for each module (which means writing two files for each module) or exporting a function that takes dependencies as arguments from every module (which requires the parent module know the child's dependencies).
+James Meyers Yeah, it's two files for each module, but that is no problem at all. Right now, I have a pattern where I have a directory for every module. So, imagine a directory called "waffle" or whatever your module is named, that contains index.js, core.js and test.js. index.is basically the same as shell.js in the example linked in the video description, i.e. the thing that welds on the "real" dependencies on the core before passing it on to parent functions. test.js is the unit tests for the core, and it tests it by creating and injecting fake versions of whatever index.js is sending in. This way, parent modules just have to require('./waffle'). They don't need to know the dependencies, that's handled by waffle. I have a project with tons of modules right now and it's working great so far.
I once was a huge fan of mocking in general. Now I don't. Problem is that if something in the underlying implementation of e. G. fs or the hue-api changes, your tests will not fail. That might be ok for your little project but for large projects with many modules in place that is horrible.
I only mock where it's absolutely not possible to test it with real implementation. The way I do it mostly than is to monkey-patch as deep a possible.
Your implementation uses a pattern just for the sake of easy testability. I found that odd.
In your very case I would just change the nupnpSearch function of the hue module by monkey-patching it.
+Stephan Hoyer Stephan, I know the allure of throwing unit tests out for integration tests. It seems so attractive. The problem you describe with underlying API changes is truth, but your integration tests approach has big downsides as well. It's just how the universe works, there are no perfect tools. If you give up on a girl just because you realize she has a bad habit, you'll never find true love. :)
Joking aside - we use both kinds of tests at spotify extensively, because both are different. I started writing about it here but realized that the answer turned into a video script. :) Until I decide to make a video about it, the the tl;dr is: that the tests you describe are what we call integration tests, and used to test the "vertical" functionality of the app, while unit tests are focus on testing "horizontally". They both have different strengths and you cannot replace one with the other, you must have them both.
Hey, I would like to do some kind of mocking for the lights, but I don't understand how the js interacts with the lights api, I am from India
Love your videos about testing!
So, I'm writing tests for a react component that takes a date as a prop (a moment object). I'm then testing if my component renders the correct number of days depending on the month. Is this a codes mell since it will break my tests if moment introduces a bug? If so, how does one handle it? Do we mock moment, or do we extract the moment-logic out of the react component? Maybe both?
PS When I say mocking, i mean mocking the behaviour if the moment functions used by the component (in this case getDaysInMonth).
Best regards,
Daniel
+gom tv it's a matter of taste. I would do it the way you do. I generally only mock things if they are stuff with side effects (such as calling the database or getting the time from the clock) or if it's external components that are complicated and I just don't want to think about it (maybe a order manager interacting with a payment system, then I might mock the entire payment system).
Dude! Your d20 kept fumbling ! No critical hits! No wonder you chose to hang it! :P
Hi. I'm trying to make a port of the code using Jest but I'm having problems finding an equivalent for the yields function in Sinon JS. Any help?
mpjme, if you write a facade for a service, as you propose in a previous video, should you write a unit test for it?
I loved the videos... and then I saw you wearing the Liverpool top. Booo! :P
How did he highlight "services" so fast ? O.o
In Atom or Sublime Text, make a text selection and press CMD+D as many times as you need (or keep it pressed). Not sure if it's a native feature of if it's added via Emmet.
does this technique fall in the injection way of unit testing?
+Sagi Avinash Varma this could be referred to as injection, yes. I don't like to use the term dependency injection as a lot of people associate it with nuclear power plant sized dependency injection frameworks like the one in Angular. This is just passing dependencies as arguments.
Do you have any thoughts about using mocha for js testing?
+Austin Wulf It's okay, I guess. I prefer tape because there is less magic involved. I always have a hard time getting mocha to play nicely with anything but mocha.
The question I keep asking myself is: is that a D10, D12 or D20. It completely takes my focus away from the rest of the video ;)
+Jeroen Rombouts haha! :) It's a D20, of course. Bought it on Etsy like a million years ago.
+mpjme Is the natural 1 intentional? :)
France onch onch onch
Canada hue hue hue
Probably a dumb question : why are you passing console (via services) into core? Isnt console available from within core already?
If I don't inject it I cannot mock it.
I.e. in the tests I want to inject a fake console so that I then can inspect the fake console in the test to make sure that the code called it.
Guatemala hue hue hue
Hong Kong hue hue hue
Color Scheme Please !!!!
for the syntax? It's just standard atom light with highlighting tweaked to yellow.
ha ! thank you very much ! I was going to go nuts trying to figure that out on my own :)
Could you subtitle this video? I would like to translate it to portuguese.
+Eliandro Daniel Ribeiro I don't subtitle them myself, sorry. It's just generous fans that do it for me sometime. :)
Brazil hue hue hue
Denmark hue hue hue.
United States hue hue hue
It looks like you are mocking the Slavic culture in this video :P
Bangladesh hue hue hue