特定领域应用框架pdf_使测试框架可读特定领域的语言

特定领域应用框架pdf

What is a Domain Specific Language you ask? In the context of a test framework, a Domain Specific Language is a readable language that uses keywords for quick test development. This allows anyone to write automated tests without any prior programming knowledge.

您问什么是特定领域语言？ 在测试框架的上下文中，领域特定语言是使用关键字进行快速测试开发的可读语言。 这使任何人都可以编写自动化测试，而无需任何事先编程知识。

Why I want to talk about this? Well, recently I dedicated my time to develop in a custom test framework of a big Belgian bank. And I noticed they used a custom DSL.

为什么我要谈论这个？ 好吧，最近我花了我的时间在一家比利时大型银行的自定义测试框架中进行开发。 我注意到他们使用了自定义DSL。

This Domain Specific Language allowed any third party to use the test framework within their own project and without the need for any prior programming knowledge.

这种领域特定语言允许任何第三方在自己的项目中使用测试框架，而无需任何事先的编程知识。

This changed my view on how testing should be performed in medium to large size companies. It is not the first time I heard of it. Nor had I seen it implemented for the first time. The difference was, it was done in a smart way.

这改变了我对应如何在中大型公司中进行测试的看法。 这不是我第一次听说。 我也没有第一次看到它的实现。 所不同的是，它是通过智能方式完成的。

Why

为什么

The idea of using a DSL in the test framework didn’t came out of thin air. There was a problem to be solved. Mainly a vast amount of people testing the applications within the company that had many different talents of which not all were programming related.

在测试框架中使用DSL的想法并非一帆风顺。 有一个要解决的问题。 主要是大量的人在公司内部测试应用程序，这些人具有许多不同的才华，但并非都与编程相关。

These people need to test the internal applications and public applications, without knowing anything about the used programming language in the test automation framework.

这些人需要测试内部应用程序和公共应用程序，而无需了解测试自动化框架中所使用的编程语言。

At that point a solution came into play: The Domain Specific Language.

那时，一个解决方案开始发挥作用：领域特定语言。

For the company the use of a custom DSL made sure that anyone can get started with programming automated tests for their project. In our case it made sure that the non-programmers could start creating their own test scripts.

对于公司而言，使用自定义DSL可以确保任何人都可以开始为其项目编程自动测试。 在我们的案例中，它确保非程序员可以开始创建自己的测试脚本。

It also allowed employing people that are talented in different fields and not only programming or test (automation) focussed.

它还允许雇用在不同领域有才华的人员，不仅专注于编程或测试(自动化)。

An Example

一个例子

After telling you all this an example really shows what I’m talking about.

在讲完所有这些内容之后，一个例子就真正说明了我在说什么。

It is important to undestand the difference between a normal test script without DSL and one that uses DSL.

重要的是要理解没有DSL的普通测试脚本和使用DSL的普通测试脚本之间的区别。

Giving an example in pseudo-code is the best way to show how it works.

用伪代码举一个例子是证明它如何工作的最好方法。

A test without DSL: Ugly and hard to read

没有DSL的测试：难看且难以阅读

import applicationDriver
import applicationClicker
import AssertapplicationDriver.create()
theWindow = applicationDriver.getWindow("Welcome Screen")
buttonResult = applicationClicker.leftClickOnButton(theWindow, "theButtonName")
applicationDriver.close()Assert(buttonResult).isNotEmpty()

A test with custom DSL: Great readability and quick to maintain

使用自定义DSL进行测试：可读性强，维护Swift

import dsl
import theWindow
import AsserttheWindow {
   perform leftClick on theButton
   clickResult = getResult()
   Assert(clickResult).isNotEmpty()
}

Is the above example with DSL the cleanest of examples? No not at all. With DSL it is all about abstraction to achieve readability.

上面带有DSL的示例是否是最干净的示例？ 一点都不。 使用DSL时，要通过抽象来实现可读性。

So even more more abstraction layers can be added? Yes! For example an abstraction layer for Assert can be added. Changing the assertion to something like:

因此，可以添加更多的抽象层吗？ 是! 例如，可以添加Assert的抽象层。 将断言更改为：

Assert clickResult toBe isNotEmpty

What it isn’t

不是什么

With the above explanation and the examples. You probably got an idea of what DSL is. Just to make sure you fully grasp it. I also have to explain what it isn’t.

通过以上说明和示例。 您可能对DSL是个想法。 只是为了确保您完全掌握它。 我还必须解释一下它不是什么。

A DSL is not equal to the well known “Gherkin” used in many test frameworks. That’s because Gherkin fits within the DSL spectrum. With our example we showed that a DSL can consist of personally defined keywords rather than for example only following the Gherkin syntax of “Given”, “When” and “Then” keywords.

DSL不等于许多测试框架中使用的众所周知的“小Cucumber”。 这是因为小Cucumber适合DSL频谱。 通过我们的示例，我们证明了DSL可以包含个人定义的关键字，而不是仅遵循“ Given”，“ When”和“ Then”关键字的Gherkin语法。

DSL also doesn’t completely get rid of programming woes. It still requires a bit of programming understanding from the DSL user and does require some maintaining and updating. Depending on the project size and its dependencies on different platforms, these tasks can get quite big.

DSL也没有完全摆脱编程的麻烦。 仍然需要DSL用户具备一定的编程知识，并且确实需要一些维护和更新。 根据项目规模及其在不同平台上的依赖性，这些任务可能会变得非常大。

The use of a DSL is not something that just instantly checks the Behaviour Driven Development (BDD) checkbox for your project. BDD is also a mindset. Using a DSL still means you have to create the test cases from which you can create the DSL-based test scripts. A DSL also comes in handy in conjunction with popular tools like Cucumber to write your test scenarios.

DSL的使用并不能立即检查项目的行为驱动开发(BHD)复选框。 BDD也是一种心态。 使用DSL仍然意味着您必须创建测试用例，然后才能从中创建基于DSL的测试脚本。 DSL还可以与Cucumber等流行工具结合使用，以编写您的测试方案。

Positive Sides

正面

I hope, by example, you understood what all the above meant and what kind of results it could have within your company.

我希望，举例来说，您了解上述所有含义以及它在您的公司中可以带来什么样的结果。

Let’s sum up some of the positives you get by using a DSL for your project. After which we also go over the drawbacks.

让我们总结一下使用DSL进行项目所获得的一些好处。 此后，我们还将克服这些缺点。

To sum up some positives:

总结一下积极的一面：

• DSL makes the code way more readable thanks to abstraction.
  DSL通过抽象使代码更具可读性。
• Anyone without programming knowledge can start automating tests. This allows for more creative input in what to test.
  没有编程知识的任何人都可以开始自动化测试。 这样可以在测试内容上提供更多的创意。
• Tests are very quick to set up.
  测试非常快速。
• No steep learning curve for any new tester.
  任何新的测试人员都不会遇到陡峭的学习曲线。

• Opens up hiring different talents within the company that can also test.

  在公司内部招聘可以测试的不同人才。

  A tester mindset is still needed though(!)

  虽然仍然需要测试人员的心态(！)

• Using a custom DSL gives a lot of freedom, so think twice before just choosing any DSL syntax (like Gherkin via Cucumber).
  使用自定义DSL具有很大的自由度，因此在选择任何DSL语法(例如通过Cucumber的Gherkin)之前，请三思而后行。

Any Drawbacks?

有任何缺点吗？

The main drawback is that a DSL requires quite an amount of extra development. Each and every main function of your framework and its implementations of the software to be tested, should be rewritten and interface with a DSL form.

主要缺点是DSL需要大量的额外开发。 框架的每个主要功能及其要测试的软件的实现均应重写，并以DSL形式连接。

Now this doesn’t mean that 100% of the supported software needs to be 100% rewritten for interfacing. Almost certain there is efficiency to be gained in some way or another. Metrics in this case show you exactly which libraries need to be supported by a DSL.

现在，这并不意味着需要100％重写支持的软件以进行接口连接。 几乎可以肯定，将以某种方式获得效率。 在这种情况下，指标可以准确显示DSL需要支持哪些库。

Another drawback is that, while it lowers the threshold for a new tester, it still involves setting up the framework at the end-user side. This comes with the needed support as well. Along with that a IDE for code/test development could scare off a test engineer.

另一个缺点是，尽管它降低了新测试人员的门槛，但仍然涉及在最终用户侧设置框架。 这也带有所需的支持。 除此之外，用于代码/测试开发的IDE可能会吓跑测试工程师。

Also the maintenance of the implemented DSL can become cumbersome. This is because DSL itself is an abstraction that doesn’t directly show what the underlying code is doing.

而且 ，所实施的DSL的维护可能变得繁琐。 这是因为DSL本身是一种抽象，不能直接显示底层代码在做什么。

Lastly. It is possible that some features of your DSL are not used by any test engineer. In that case it is highly recommend to add the gathering of metrics in the test framework. This way you exactly know which functions are used the most and which are not. For example; This might show you that the test engineers aren’t using a password security feature, that might be necessary for operations or required per business or law standards.

最后。 DSL的某些功能可能没有被任何测试工程师使用。 在这种情况下，强烈建议在测试框架中添加指标的收集。 通过这种方式，您可以准确知道哪些功能使用最多，哪些功能没有使用。 例如; 这可能表明您测试工程师没有使用密码安全功能，这对于操作或业务或法律标准可能是必需的。

Conclusion

结论

After reading all the above, you probably understood what DSL can mean for yourself, your team and company.

阅读以上所有内容后，您可能了解DSL对您自己，您的团队和公司的意义。

DSL does have drawbacks, but compared to the benefits, it still is a great route to follow for your test automation approach. Atleast for me a test automation project for a medium to big sized company isn’t complete without including a DSL.

DSL确实有缺点，但是与优点相比，它仍然是您进行测试自动化方法的绝妙途径。 对我来说，Atleast在没有DSL的情况下无法完成针对中型公司的测试自动化项目。

The main benefit I take from using a DSL is the fact that it allows writing automated test scripts very quickly and makes them readable. It will not only make me happy when I program, but also my future successor. As there is no better feeling than instantly grasp the concept of a test automation project because the current and previous developers made the right choice from the start.

使用DSL的主要好处是它可以非常快速地编写自动测试脚本并使它们可读。 这不仅使我在编程时感到高兴，而且使我将来的继任者高兴。 因为没有比立即掌握测试自动化项目的概念更好的感觉了，因为当前和以前的开发人员从一开始就做出了正确的选择。

Hit me up

打我

I hope you learned something through my article. If you have any more questions or doubts, hit me up. We could grab a drink together in Belgium or The Netherlands, and talk about what keeps us busy. I would love to hear from you!

希望您从我的文章中学到一些东西。 如果您还有其他疑问或疑惑，请打我。 我们可以在比利时或荷兰一起喝一杯，然后聊聊让我们忙碌的原因。 我希望收到您的来信！

翻译自: https://medium.com/@bas.dijkstra54/making-test-frameworks-readable-the-domain-specific-language-c154c9a9abcb

特定领域应用框架pdf