 So, I'm Kelly. Pablo asked me to fill in for a speaker, and I whipped these slides together really quick about something I've been working on. It's another browser test runner. And coincidence that Sam did something very similar last time, I swear. Obligatory slides about where I come from. I'm on the Ember team. Crowdstrikes, always hiring, all levels. Non-Ember people are welcome, but we're all Ember and open source friendly. Should mention this is like lightning style. It's pretty fast. Wants. We are Crowdstrike. We're looking to solve our end-to-end problems, all of our testing laws. We had a lot of wants to be as real as possible. So no in-browser injection techniques like Cypress were going to work for us. Browser agnostic. So this also excludes stuff like Cypress and Puptier as they're very Chrome-centric. Flexible, powerful, enterprise, insert random buzzword. We're testing a massive application. Getting started guide, testing a to-do app, isn't really going to cut it. So we chose web driver solution, all said and done. The trade-offs of how easy it is to get your first test up and running versus everything we need out of a testing framework. It just wasn't there for the newest Chrome-based techniques. Our requirements were almost too many to list. A CLI. Other teams are going to be running our test without cloning our source code. So every feature needs a CLI option. Test filtering. Reject support for running certain test names. A lot of test runners have this. Test tagging. A convenient way to decorate tests, to run them in groups. Whether you mark them as slow, you mark them as fast, smoke, whatever. Role support. So we want logging in and out and role switching and context switching. Shared sessions all built in. Environment support. So you say I'm running against prod or dev and you can target different URLs or different servers. And target support, which is basically whatever you want it to be. So we set up a target of default for normal and then a target of mock for testing just mock data, or if we're flying on a plane and we need to work feature flags. So you may gradually roll out changes to your environments and you want to prevent some of your tests from running until they turn on. So you can get your test behind whether feature flags are on or off. And I'll show off file test. It's the open source web driver framework to solve our problems and how you can use it yourself if the other frameworks are too limited for you. So using the CLI example of just targeting whatever browser you want. Filters, pretty basic rejects. I'm matching both tests with foo and just the last one with Baz. Test tagging. So it's kind of like Twitter style taggings because these aren't, the tests aren't quite classes. So decorators don't really make sense. So it's kind of like a decorating style. You just tag your tests and you can target them using the name or not to exclude them. Roles, they're also just tags. So you just get another, like describing it in mocha, you just get another one called roles and you can put as many as you want in there and it'll say these tests can run under these roles and then you can run your suite against them. Environments, pretty simple. They just give you a way to hit a different URL if you want. Nothing, other, nothing fancier than that. Targets, like I said, it basically just lets you code whatever you want a target to be, but it gives you a neat way to, to use them. This is what a feature flagged test looks like. It's kind of, it's just, it's just like a super syntax on mocha currently was might support other test runners, but it's all mocha flavored right now. So the, the, it looks kind of like mocha except if you put an option with flags, you can say that this test runs with feature one turned on and if feature two is off, plus a lot more optional stuff that I can spend all day going over, but just give you a second to soak that in, I guess demo time. So yeah, this is the source code for file test. And this is one of the examples I was just filling out. It isn't hitting on the page objects yet. I'll still convert these to page objects. It's just calling the normal web driver calls. But it exercises most of the options. Looks just like mocha pretty much. You get a few more helpers. So I'm saying this, this test suite, let me expand just to, it's good enough. This test suite runs under these two roles, ones I just made up. And this is your login hook. It manages all that for you, depending on what options you want. So it'll just get called whenever it needs to log in. So you don't have to worry about it. But it gets invoked and then you'll hit your URL. And this is just a code pen I built for a dummy login flow. But I use different code pens to designate environments. As you can see right here, I have, my target is just a query param, but it can be whatever you want it to be. It's passed into you right here. And I fill in the form and log in. And then right down here is the feature flags. So you have to tell FALTES what your feature flags are, where to get the data source. So you can see that when it hits the browser, it's just something I threw on window. It's wherever your feature flags are, you would just go query it. And so let me just start it up. Let me pull up the VS code config as well. So I'm hitting, I just, Chrome is the default, but I just picked Firefox for this demo. I'm hitting dev with fixtures. I'm saying use a role and smoke tests. And so it hasn't visited anything. So I'll step over this. There it is. It's dev fixtures. I'll just go ahead and fill in the form. Go get the feature flags. There they are, my feature flags. And then that's going to be my assertion down there. Is the member section showing? Yes, okay. You're done. So it's a very simple demo for this case. Let me go fiddle with some options. I'll scroll down here and it's got some feature flagged tests. If your feature is finished, run this test. All the environments have this. So this will run all the time. In progress feature, if that's enabled, run this test and that only happens in dev. And then if not in progress, which would be our prod environment, it'll run this test. And so this is a negative feature flag test. So you're saying prod, which shouldn't have this feature on, test that it doesn't have the feature on. And so for us, we have lots of different clouds for various different reasons. And some of them are just going to have a feature flag turned off forever. They don't get a normal feature. And so we're going to have very valid tests that are going to say, make sure that feature is never turned on in this cloud. Otherwise, bad things will happen. So it turns out these not feature flags are pretty convenient. And so if I go over here and I'll just comment that out. So it was just targeting the smoke tag, which was right there. I'll get rid of these two, run it in prod and run it in dev. Oh, sorry, prod and Chrome. Yeah, I'll change this to admin too. And mainly, I'll just let it fly through these tests, but I was just going to show the console I'll put. So these are prod hitting prod. And so it's saying this in progress feature, it doesn't exist on prod. So it skipped the test. But this not feature flag, it like targeted prod. So it made sure that this feature was not turned on in prod. And then this feature is already turned on. So it ran. And then, you notice the browser was flashing every test. And that's just it. That's the most safest way to run it. You get a new context every time you have to re log in. But you can just turn on share session. And it's going to fly through the test. It's not going to re log in between them all. And they're all done. And then, so that's my, my simple demo. And then for my one last one, I want to show it off running on a real application. So I'm going to demo hitting, hitting our CrowdStrike app. And so it's going to be hitting our prod environment, but it's all test data. It's a test user I created. Ember London is the role I created. And then that role is associated just to mock data on our site. Configuration is our section of the app that we're going to target. So there's a lot of tests in configuration. And then I'm going to filter down just one test using a regex, the exclusions groups test. And then I'll just run it. And it's going to be a normal test. You'll just see a bunch of, bunch of operations. But our code is probably like maybe 20 lines to run this test. So you can do all that Cypress too, but this is just using all of our helper functions in this framework. The amount of code you have to write to get all this logging in and all this targeting of feature flags. It's all pretty concise. This is the URL I just got published this morning. Some of the future plans are, right now it has a page object system. It works pretty nice in my opinion, but one of the things we want to do is make it so that our Ember test suite and our smoke test, test suite share the same page object system. And so that's something I want to do relatively soon. It's not there yet. We have two, we have Ember CLI page object and then this page object system. And they're pretty much duplicated. We want to get rid of that. And then since I just published it this morning, I have a lot to read me expansion to do. I did a one pass and documented a bunch of stuff, but it needs more work. So if you want to start using it, feel free to reach out and I'll help you out. And I'm just curious if anyone likes to try it. Thanks.