Easy-Bake Testing
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 37 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/34695 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 201630 / 37
4
5
7
10
11
13
14
15
16
17
20
23
24
25
26
27
29
30
31
32
00:00
CodeVideoconferencingStatistical hypothesis testingDisintegrationExecution unitSoftware frameworkDependent and independent variablesDefault (computer science)Control flowSynchronizationJava appletScripting languageComputer configurationNumberStatistical hypothesis testingMultiplication signExecution unitLibrary (computing)SubsetProjective planeSoftware frameworkStatistical hypothesis testingPeer-to-peerRoutingUniform resource locatorDependent and independent variablesCuboidIntegrated development environmentAutomationDefault (computer science)PressureKey (cryptography)Task (computing)Web pageSoftware developerVolumenvisualisierungCodeTheoryCoefficient of determinationRight angleOcean currentGrand Unified TheoryEvent horizonDifferent (Kate Ryan album)Order (biology)Group actionINTEGRALSynchronizationElectronic program guideComputer animation
04:10
Message passingEquals signStatistical hypothesis testingMessage passingSet (mathematics)Uniform resource locatorOrder (biology)Line (geometry)Group actionDirected graphBuildingComa Berenices
04:59
CodeStatistical hypothesis testingFunction (mathematics)Execution unitINTEGRALStatistical hypothesis testingCodeExecution unitLevel (video gaming)Unit testingInteractive televisionDifferent (Kate Ryan album)Set (mathematics)SubsetStatistical hypothesis testingFunctional (mathematics)Order (biology)Computer animation
05:30
Inheritance (object-oriented programming)SpacetimeNeuroinformatikExpected valueUnit testingCategory of beingMedical imagingComputer animation
06:00
DisintegrationEuclidean vectorTemplate (C++)Component-based software engineeringStatistical hypothesis testingConnectivity (graph theory)INTEGRALStatistical hypothesis testingTemplate (C++)Statistical hypothesis testingUnit testingCuboidCartesian coordinate systemCASE <Informatik>Lebesgue integrationComputer animation
06:29
Electronic visual displayComponent-based software engineeringTemplate (C++)Normal (geometry)Electronic visual displayElectronic mailing listMobile appConnectivity (graph theory)Term (mathematics)
07:01
SubsetINTEGRALStatistical hypothesis testingSampling (statistics)Mobile appMereology
07:22
Uniform resource locatorSynchronizationStatistical hypothesis testingTemplate (C++)Home pageDirected graphCovering space
07:45
Online helpExecution unitStatistical hypothesis testingLibrary (computing)Function (mathematics)Exception handlingSystem callLatent heatCodeForceDependent and independent variablesInheritance (object-oriented programming)Integrated development environmentDatabaseNumberElectronic visual displayHome pageLibrary (computing)Statistical hypothesis testingStatistical hypothesis testingWritingSoftware developerBlogMultiplication signFunctional (mathematics)Dependent and independent variablesACIDExecution unitEvent horizonProjective planeSubsetLink (knot theory)Exception handlingInformationFactory (trading post)Sign (mathematics)HoaxExpected valueParameter (computer programming)Integrated development environmentAreaDatabaseSystem callUnit testingRow (database)PlanningCodeOnline helpQuicksortDoubling the cubeQueue (abstract data type)Latent heatGoodness of fitComputer animation
10:33
Server (computing)Dependent and independent variablesPatch (Unix)outputCommon Language InfrastructureError messagePasswordDependent and independent variablesLine (geometry)Error messageServer (computing)PasswordStatistical hypothesis testingSoftware frameworkComputer animation
11:06
Binary decision diagramSoftware frameworkSimilarity (geometry)Library (computing)Statistical hypothesis testingArrow of timeKeyboard shortcutStatement (computer science)Context awarenessFunction (mathematics)Integrated development environmentBuildingWritingWeb pageData structureEncapsulation (object-oriented programming)BlogArrow of timeTest-driven developmentDifferent (Kate Ryan album)Web browserAxiom of choiceFunctional (mathematics)Cartesian coordinate systemStatistical hypothesis testingIntegrated development environmentWeb pageCuboidCommon Language InfrastructureHookingStatistical hypothesis testingObject (grammar)Multiplication signMessage passingData structureComplete metric spaceTerm (mathematics)Point (geometry)Social classMathematicsSoftware frameworkLibrary (computing)1 (number)Similarity (geometry)Software developerExecution unitStatement (computer science)Context awarenessComputer virusNumberFamilyHome pageInsertion lossArithmetic meanSubsetComputer animation
15:19
outputServer (computing)Patch (Unix)Dependent and independent variablesError messagePasswordElectric currentEquals signMathematicsObject (grammar)PasswordSet (mathematics)Software developerWeb pageError messageoutputFunctional (mathematics)Statistical hypothesis testing
16:12
Statistical hypothesis testingCodeObject (grammar)Web pageFunction (mathematics)DisintegrationLattice (order)Execution unitStatistical hypothesis testingDependent and independent variablesBlogGodStatistical hypothesis testingStatistical hypothesis testingBlogBitDifferent (Kate Ryan album)Unit testingGreatest elementImplementationCommon Language InfrastructureOcean currentInteractive televisionLink (knot theory)Electronic program guideMathematicsInformationRow (database)Mobile appWritingExecution unitWeb pageLebesgue integrationCodeOperator (mathematics)Integrated development environmentProcess (computing)Discrete groupFunctional (mathematics)Sound effectINTEGRALNeuroinformatikLocal ringCategory of beingCellular automatonObject (grammar)Software frameworkComputer animation
Transcript: English(auto-generated)
00:15
to talk to you about testing. I hope you're ready. So last year, I don't know how many of you
00:21
were here last year, but I gave a lightning talk with 24 hours of notice after much peer pressure from Leah on the topic of testing in Ember. At the time, I had three months of experience as a professional developer.
00:40
I had freshly graduated from the Flatiron School. I didn't really know that much about testing at all, and I found that there were not that many great resources. So hence, I felt much like our friend chemistry dog here. I had no idea what I was doing. So I gave this talk on like, you know, your testing resources suck.
01:04
So I'm back now, and I'm here to share with you all the things that I wish that I had known last year. Basically, I'm going back in time. So travel with me. I'm going to talk to my past self, because now I have some idea of what I'm doing.
01:23
So first of all, what do I wish I knew a year ago? First of all, what do I have access to with Ember right out of the box? Without even thinking about it, what am I getting? How do I use Ember's built-in test helpers that Ember gives us right out of the box? What's the difference between unit acceptance
01:42
and integration tests? At the time, I think the Ember guides kind of conflated acceptance and integration a little bit. It was very confusing for me. I think it's since been remedied. But what's the deal with all these other frameworks and libraries? I kept hearing people, whenever I'd go into like, you know, a testing room or whatever, everyone would be like, oh, Jasmine, Jai, Iq, and there's all this stuff.
02:03
And I was like, well, do I need that stuff? Is that important? I have no idea. What are mock stubs and spies? Do I need them? How can I mock API responses? Obviously, you don't want to be hitting your API live all the time in your testing environment. That's terrible. So how can I mock those API responses for my tests?
02:22
How do I deal with async behavior? And finally, what are some best practices when it comes to testing? So what do I get without even trying? I can roll out of bed, and there's QUnit ready for me. So QUnit is a JavaScript testing framework. It's not specific to Ember.
02:41
It's a JavaScript testing framework. You can use it with any JavaScript project. But Ember gives it to you right out of the box. It's a default testing framework. So when you have an Ember app, it includes everything that QUnit has. So if you go to the QUnit documentation, you'll see all the assertions they give you and all the cool helpers and all that stuff.
03:02
And you have all of that. Ember test helpers. These are built-in methods to automate common tasks in acceptance tests, like visiting a page, clicking a button, all that fun stuff. Test them, very simply. Test runner runs your tests. So the Ember acceptance test helpers, there's three groups.
03:23
The first is async. These are helpers that are aware of and they wait for your async behavior. They are run in order. And they are click, fill in, key event, trigger event, and visit. They're fairly self-explanatory,
03:41
but if you want super detail, you can look in the Ember guides. So the sync test helpers. The sync test helpers are performed immediately when triggered. Some of those are current path, current route name, current URL, find. And finally, the wait helpers, which is really just one helper, and then.
04:04
So and then waits for all the preceding async helpers to finish before executing the code wrapped within. So here's an example. This is a test that is, we're just testing that if I visit a certain URL and I click on a certain selector, then I'm not gonna be redirected
04:22
and I'm gonna see this warning message. So you see on line two how many assertions are expected. You see on line four an async helper in action. That's visit. More async on six, click. So those happen in order. And then waits for those guys to finish. We have our key unit assertions.
04:42
We're asserting that the current URL is not equal to settings slash billings and that the warning message selector text is an account already exists for shared at example.com. So that's some examples of those helpers in action.
05:00
What's the difference between the different kinds of tests? We have unit tests, integration tests, and acceptance tests. Unit, integration, acceptance. Like the stages of grief. Nailed it. So unit tests, first of all, are self-contained tests.
05:20
You're only testing the code itself with unit tests. You're not testing user interaction. You're testing only a particular function or another unit of code. This is not clicking, visiting, whatever. So to give you an example, we have this super basic computer property full name just takes first name, last name, concatenates them with a nice space in the middle. Super basic, so we're just gonna
05:42
write a little unit test for that. That full name returns first name and last name. So we're just making a user, setting the first and last name properties to Bob Smith, and then we're asserting that when we call user get full name that we get Bob Smith, as expected. So that's an example of a unit test.
06:00
Integration or component tests. Component tests are integration tests, but integration tests might not be component tests. When you generate a component using Ember CLI, it comes with a little component test out of the box, which is an integration test. Basically, you're testing how one layer
06:20
of your application interacts with another. In the case of components, it's usually how components interact with each other or with other templates. So we have this little component. It's just a list of dudes. Joe, Bob, Bob Joe, Joe, Bobby, Joseph, Robert. For some reason, these guys are really important, and we want their names all over our app.
06:41
So we made this little component called list display. And then we're just testing that when it renders that they are there. So it's pretty simple. This dot render, list display, and then you see the assertion that when we trim all the text, that we get what we expect.
07:02
Acceptance tests. So acceptance tests and integration tests can be tricky to pull apart. But acceptance tests, the way I remember it is that I accept that my app has actual users who will actually interact with it. So I had better well tests for that. Because they're gonna click that button that you don't want them to click, and you gotta be ready for that.
07:22
So again, we have Joe, Bob, Bob Joe, Joe, Bobby, et cetera. This is just a plain template. And so we have two acceptance tests. The first is that when we visit the homepage, it results in a current URL of the homepage. So we see, again, the async helper visit, and then waiting, assert equal, current URL,
07:42
that's one of our sync helpers, is equal to slash, simple enough. And then the correct number of users are displayed. So again, we visit the homepage, and we check that the number of users that we expect are there. Mocks, spies, and stubs. Mocks, spies, and stubs,
08:00
they help you write unit tests in isolation. They probably won't come up very often in Ember, but they're good to be aware of. I was only made aware of them because I was working on a plain JavaScript project at my last job, and they had all these things, so that's how I became aware of them. But they're really more for unit tests, and you should mostly be writing acceptance tests,
08:22
and unit tests you should write the least of, so it's not gonna come up that much. Sinon.js is a great library that provides mocks, stubs, spies, and more. There are also two highly rated Ember sign-on add-ons called Ember sign-on and Ember sign-on queue unit that you can look into if you wanna use these things.
08:40
And there's also a link to a blog post that I found about using sign-on in Ember projects. So mocks are also known as test doubles. These are fake methods with pre-programmed behavior and pre-programmed expectations. Spies, a spy is a function that records arguments,
09:02
returns the value, as well as the value of this, and any exceptions that might be thrown for all its calls. It's good for seeing how many times a particular function was called, or how a function is handling a specific callback. And stubs, stubs are spies, so you get everything that you get with spies with stubs.
09:21
They kind of help you force your code down a specific path, so if you wanna throw an error, or you have a specific sort of path you wanna go down, they're good for that. In the case of sign-on.js, there's a lot to explore. Stubs, like I said, they support the full spy API, so if you look at the documentation, you can find tons of information.
09:40
And mocking API responses. So this is pretty important, because you don't wanna be hitting your live API. Obviously, you want your tests to be running in isolation. A great solution that I love for it, and I think a lot of people love for it, is Mirage. Mirage is awesome, super popular solution, not just for testing.
10:01
It can be used in development as well as in test environments. They offer factories that you can use for tests. You can seed your test database ahead of time. You can mock one-off responses in individual tests. Sign-on also offers mock API responses, but Mirage just offers so much more
10:21
that it's definitely worth looking into. And like I said, you can use it in development, so if you don't have an API that's ready yet, and you just want a mock API to work with in development, you can use it for that as well. It's awesome. So here's an example of where you might use Mirage. We're just testing that someone who's entering,
10:43
they're changing their password, and they enter an incorrect password, and we wanna make sure that this error is gonna get thrown, but we need to get that response from the API. That old password is not correct. So you can see from lines four to eight how Mirage works there, just like server.patch,
11:00
and you say what you want, and then you throw whatever the response is. Framework FOMO. So if you're anything like me, last year, a year ago, you might be seeing everyone talk about all these different testing frameworks and libraries and stuff, and you're thinking like, God, do I need this? Like, how do I know which one I should be using?
11:22
So I looked into a couple of the ones that I heard a lot about, and kind of compiled a bunch of the different, whatever I could tell was slightly different about them. So Jasmine is the first one. It's a behavior-driven testing framework. Doesn't require a DOM.
11:40
Doesn't depend on any other frameworks. It's similar in syntax to RSpec, which I think is the biggest selling point if you're a developer coming from Rails background. I've heard that Jasmine is a little easier to pick up, but I also came from a Rails background, so I really didn't find QUnit difficult at all to pick up. So, you know, to each their own.
12:01
Chai is an assertion library, not a framework. People seem to really like having a ton of different assertions. It's, you know, it's a personal choice. I find QUnit to be more than enough, but if you really wanna have that, then Chai could be a good solution for you. I've heard that it's difficult
12:20
to implement an ember with QUnit. There's a few add-ons out there, but I couldn't find one that seemed to be, like, a distinct solution. However, there's Mocha, which is another testing framework, so you would probably use this in place of QUnit. You can use any assertion library, so if you really like Chai, you can always just use Mocha instead of QUnit. I've read that you can't use the ES6 fat arrow syntax.
12:44
I don't know if that's true, but it seems weird. Apparently, the reason for this is that their lexical binding of this value makes them unable to access the Mocha context, so statements like this.timeout 1000, it won't work inside an arrow function. I don't know why.
13:01
So, Selenium. Another one I've never used, but I've heard a lot about. It's mostly for end-to-end testing, clicking and all that. It drives your browser in your application environment rather than test environment. I've heard it's difficult to hook up to ember and that it's much slower than using QUnit.
13:23
So, what's the verdict? As far as I'm concerned, QUnit is great. I have yet to come upon a situation in which I felt like QUnit was lacking. So, I think everything that comes out of the box is awesome, except for you should add Mirage, because that's great. Okay, TDD.
13:40
So, if you're a beginner, like I was a year ago, you might hear this term thrown around. What's TDD? TDD is test-driven development. It means that, basically, first you write a failing test for something that doesn't exist yet. Then you build the thing to make the test pass. You write another test for another thing that doesn't exist yet, and you rinse, repeat.
14:02
This is a great way to ensure as complete test coverage as possible, but a lot of beginners find it very difficult if you're trying to do this without any guidance, because a lot of the time, as beginners, you'll find that you are just kind of hacking something together, and you don't really know what it's gonna be when you're done, and so it's impossible
14:20
to know what it's gonna be ahead of time to test for it. So, it's okay if you try to do TDD, and you're a beginner, and you have a hard time. You know, there's nothing wrong with you. Page objects, okay. So, UI changes can make your tests really brittle if they're frequently dependent on specifically named selectors.
14:41
You might find that you make a lot of changes to a bunch of classes, and all of a sudden you have all these tests failing, because you're depending on all these classes and all your acceptance tests. So that's annoying, but page objects are a great solution for that. Basically, just you encapsulate the structure of your page within an object. So, this helps keep your, it helps keep your tests dry,
15:02
as well as keeping the intention of your tests clear. There's a well-supported Ember add-on that looks awesome called Ember CLI page object, and there's also this famous blog post by Martin Fowler on the topic of page objects, if you wanna read more about them in general. So, here's an example of where we might
15:21
use page objects. We have that same test again, we're using Mirage, and we've got all these, there's a ton of selectors here. You know, you've got the change password selector, new password, input, whatever. So, let's make a page object for the account settings page, and let's just encapsulate all that stuff.
15:43
So, when we're visiting, let's just make a visit function, let's just make a click change password, so it's very obvious what's going on. And then, when we go back to the test, you can see it's very obvious the flow, like if you just hired a new developer and they come in and they look at this test, they know exactly what's going on. You visit the page, you click change password,
16:01
you enter incorrect current password, enter the new password, update the password, and then, you know, you wanna see that the password error text is equal to that text. So, it makes it a lot easier. Some best testing practices that I have come upon. Keep your test code dry by writing test helpers.
16:21
So, if you find yourself repeating your code over and over in your tests, Ember allows you to write custom test helpers, and there's a lot of information about that in the Ember guides. So, if you find yourself doing that, start writing some test helpers. It'll make everything happy. Protect your tests from UI changes
16:40
and keep their intention clear with page objects, as I just talked about. Keep each test discreet in its functions. So, you don't wanna be testing five different interactions in one test. You wanna make sure that you're keeping everything very discreet and isolated, as isolated as you can. Most tests should be acceptance, some integration, least of all unit.
17:00
This is my opinion. Katie Gengler gave a talk a while ago where she had like a pyramid, I think. I think it was her. And it was a little bit of unit at the top, in the middle was integration, and the bottom was acceptance. And since Ember is a front-end framework, it makes sense that you wanna mostly test your user interaction and clicking around
17:21
and stuff like that. But if you have like a really complex computed property, then obviously you might want a unit test for that. Testing styles like TDD. They're a matter of personal preference. Not any better or worse than anything else. They're worth looking into. I think TDD is super interesting. I just haven't been able to use it very much myself.
17:42
Some resources, the Ember guide link to the test helpers, Q unit docs. I also gave a talk at the global Ember meetup like a few months ago called Intro to Testing, and that's just like a step-by-step like nitty-gritty, how do you actually run your tests? What's the difference between all the test environments? So if you're interested in that,
18:01
that can give you more information about that. And some more links to all the different things. And a great blog post I found about the differences between mocks, stubs, and spies. Finally, I would love to thank my former coworkers at SimpleReach who are all in the front row.
18:21
They were my, thank you, Haejin. They were my coworkers a year ago. I came here with most of them a year ago, and they were very, SimpleReach was very supportive of me as I was trying to learn testing on the job, and basically they were like, we don't have any tests in this app. Why don't you learn testing and write all the tests for this app?
18:40
So I wouldn't have learned all this stuff without SimpleReach, and also, I just moved here two months ago from New York working at SimpleReach, and now I work at Tilda, which is amazing and awesome, and I would also like to thank my current coworkers and team members at Tilda. That's it, thank you very much.
19:08
Hi, I have a question about coverage tools, and I've been trying to integrate Blanket, for example, and with Ember CLI, it's kind of a hassle, so any suggestions would be appreciated.
19:22
I actually didn't, we, at my last job, I think we did implement Ember CLI Blanket, but I didn't do it, Andre did it. Because I think I tried, and I just couldn't. It was so hard, but Andre Milan can help you a lot with that.
19:42
Anyone else? Oh, thank God. Thank you.