驯服烂代码_驯服业力，SauceLabs和Internet Explorer：揭秘之旅

驯服烂代码

by Gregory Beaver

通过格雷戈里·海狸

驯服业力，SauceLabs和Internet Explorer：揭秘之旅 (Taming Karma, SauceLabs and Internet Explorer: a journey revealed)

It seemed simple enough.

看起来很简单。

Just set up karma with TravisCI to run tests on SauceLabs so I can be certain my code doesn’t break the internet when Granny wipes off the cobwebs and fires up Internet Explorer to browse to a site that uses my code.

刚刚成立的业力TravisCI上运行测试SauceLabs所以我可以肯定我的代码不会破坏互联网时老太擦去蜘蛛网和火灾高达Internet Explorer浏览到使用我的代码的网站。

At first, it seemed like the hardest challenge would be to set up karma.conf.js. My project, react-selection-hoc, is a React component that allows any list of things to become selectable using Higher Order Components. Long story short, I want to make sure that it works on every browser it could work on.

起初，似乎最困难的挑战是设置karma.conf.js。 我的项目react-selection-hoc是一个React组件，它允许使用高阶组件来选择任何事物。 长话短说，我想确保它可以在所有可以使用的浏览器上运行。

The project is written in ES6 and JSX, so for karma to work, I needed to somehow package up the code in a way that babel could convert it to es5. This turned out to be much harder than I expected. Eventually, I found the solution in the way that react-big-calendar handles it, by packaging up the tests with the karma-webpack plugin. This worked with the local Chrome browser fabulously. Done!

该项目是用ES6和JSX编写的，因此为了使业力正常工作，我需要以某种方式打包代码，以便babel可以将其转换为es5。 事实证明，这比我预期的要难得多。 最终，我通过使用karma-webpack插件打包了测试，找到了一种以react-big-calendar处理它的方式的解决方案。 这与本地Chrome浏览器完美配合。 做完了！

Next step: get SauceLabs set up. Note: I did consider using BrowserStack, which is oh-so-sexy and the best thing ever for manual testing, but the automated tests have some limitations that meant the test suite ran about 10–15 minutes slower than SauceLabs. Some of it was the limited free account, some of it is design, but ultimately SauceLabs works better for my needs. If I was closed source with mega-bucks, I would probably go with BrowserStack, but that’s neither here nor there.

下一步：设置SauceLabs。 注意：我确实考虑过使用BrowserStack ，它非常性感，对于手动测试是最好的，但是自动测试有一些限制，这意味着测试套件的运行速度比SauceLabs慢10-15分钟。 其中一些是有限的免费帐户，一些是设计帐户，但最终SauceLabs可以更好地满足我的需求。 如果我是大笔钱的封闭源，那我可能会选择BrowserStack，但这既不是这里也不是那里。

Setting up SauceLabs is hard. Not because it is hard, but because the documentation is scattered all over the universe. The configurator for SauceLabs is out of date, but by triangulating with the platform list, it is possible to create an array of browsers that will work.

设置SauceLabs很难。 不是因为很难，而是因为文档分散在整个宇宙中。 SauceLabs的配置程序已经过时，但是通过对平台列表进行三角剖分，可以创建一系列可以使用的浏览器。

In addition, I wanted to be able to quickly develop a test locally, using karma’s autowatch feature, sort of a Hot Module Reload for testing. The way I solved this initially was to use a separate command for local testing, which passes an environment variable into karma that causes it to use only the local Chrome browser with singleRun set to false. Disable the QUICKTEST environment variable, and it connects to saucelab. Of course, I have to remember to start the saucelabs connect tunnel and you shouldn’t forget this when running your own setup.

此外，我希望能够使用karma的自动监视功能在本地快速开发测试，这种功能类似于热模块重载以进行测试。 我最初解决此问题的方法是使用单独的命令进行本地测试，该命令将环境变量传递到业力中，从而使其仅使用将singleRun设置为false的本地Chrome浏览器。 禁用QUICKTEST环境变量，它连接到saucelab。 当然，我必须记住要启动ucelabs连接隧道，并且在运行自己的设置时不要忘记这一点。

Long story short, here is the first working setup I used! All seemed well until…

长话短说，这是我使用的第一个工作设置！ 一切似乎都很好，直到…

炼狱开始 (Purgatory begins)

Part of my goal with the unit tests for react-selection-hoc is to ensure that browser quirks are tested and accounted for so that any contributions have a test framework to ensure they aren’t breaking anyone else’s install. The code only uses a couple of DOM-specific measurement functions to determine whether a click/tap or mouse/finger drag is over a selectable element or not. It should be simple to test these right?

我对react-selection-hoc的单元测试的目标之一是确保对浏览器的怪癖进行测试和说明，以便任何贡献都具有测试框架，以确保它们不会破坏任何其他人的安装。 该代码仅使用几个特定于DOM的度量函数来确定单击/点击或鼠标/手指拖动是否在可选元素上方。 测试这些应该很简单吗？

In order to test these simple things in all browsers authentically, to truly verify the correctness of the code, it means modifying the DOM and then querying it. Because of how Karma works, this means the actual testing environment is modified, which is where we enter purgatory in this story.

为了在所有浏览器中真实地测试这些简单的事情，以真正验证代码的正确性，这意味着修改DOM，然后对其进行查询。 由于业力的运作方式，这意味着实际的测试环境已被修改，这就是我们在本故事中进入炼狱的地方。

Because of how Karma works, this means the actual testing environment is modified, which is where we enter purgatory in this story.

由于Karma的运作方式，这意味着实际的测试环境已被修改，这就是我们在本故事中进入炼狱的地方。

At first, things seemed cool. I found edge cases that didn’t work in iOS and Internet Explorer, fixed them, and moved on to other things. Then, I started to notice tests failing randomly that had been working before.

起初，事情看起来很酷。 我发现在iOS和Internet Explorer中无法使用的边缘保护套，对其进行了修复，然后转移到其他方面。 然后，我开始注意到以前一直无法正常进行的测试失败。

But the worst part was when I ran the IE tests in isolation, which is to say only on Internet Explorer and Edge, they all passed. Every. single. time.

但是最糟糕的部分是当我单独运行IE测试时，也就是说仅在Internet Explorer和Edge上，它们都通过了。 每一个 单。 时间。

So, to rectify this, I first tried putting the DOM manipulation code in their own describe blocks, with before/after code to set up the manipulation. No improvement. Then, I tried setting useIframes to false, which tells Karma to run the tests in a separate window. This worked great for Internet Explorer, but broke every single mobile browser, and left me in a puddle of despair.

因此，为了纠正这一点，我首先尝试将DOM操作代码放入自己的describe块中，并使用之前/之后的代码来设置操作。 没提升。 然后，我尝试将useIframes设置为false，这告诉Karma在单独的窗口中运行测试。 这对于Internet Explorer来说效果很好，但是破坏了每个移动浏览器，使我陷入绝望。

解决方案或必杀技出现 (The solution, or nirvana appears)

The moment of enlightenment finally came today. On a whim, I decided to see what would happen if I ran 2 sequential runs of karma with the same build ID for saucelabs. To my delight, SauceLabs obediently grouped all the tests together. So, I refactored all of my karma configuration files, did away with the environment variable-based solution, and ended up with this perfect, working solution:

启蒙的时刻终于到了今天。 一时兴起，我决定看看如果我连续两次运行具有相同版本ID的酱场的业力时会发生什么。 令我高兴的是，SauceLabs乖乖地将所有测试组合在一起。 因此，我重构了我的所有业力配置文件，取消了基于环境变量的解决方案，最后得到了一个完美，可行的解决方案：

In my package.json, all I need to run all tests is:

在我的package.json中，运行所有测试所需要做的就是：

"test": "karma start karma.noie.conf.js && karma start karma.ie.conf.js",

I hope this solves someone else’s conundrum. Karma + SauceLabs is a fantastic way to test both high-level code and very low-level assumptions about how browsers work to ensure that your issue tracker won’t fill up with annoying should-have-tested-that bugs.

我希望这可以解决其他人的难题。 Karma + SauceLabs是一种出色的方法，可以测试有关浏览器工作方式的高级代码和非常低级的假设，以确保您的问题跟踪器不会充满烦人的本应测试的错误。

Happy testing!

测试愉快！

翻译自: https://www.freecodecamp.org/news/taming-karma-saucelabs-and-internet-explorer-a-journey-revealed-548275ed04b4/

驯服烂代码