如何使用Gherkin根据授权测试过滤器? [英] How to test filters based on authorization using Gherkin?
问题描述
我不了解当没有实际的业务操作来测试某些东西时，场景的外观如何.
I don't understand how should scenario look like when there is no actual business action to test something.
以下情况是否足够好?我不明白如何将其转换为过去，动作，未来序列.
Is the following scenario good enough? I don't understand how it can be converted into Past, Action, Future sequence.
Scenario:
Given The system contains the following users
| email | role |
| admin@example.com | ADMIN |
| user@example.com | USER |
And The system contains the following Products
| Name | Active |
| Product1 | true |
| Product2 | false |
Then The list of Products for 'admin@example.com' user should contain the following entries
| Name | Active |
| Product1 | true |
| Product2 | false |
And The list of Products for 'user@example.com' user should contain the following entries
| Name | Active |
| Product1 | true |
推荐答案
tl; dr
通信，如果费劲的话.将行为(即"when"子句)嵌入要求中比较好(IMO).
tl;dr
Communication if figgin hard. Embedding behavior (ie a "when" clause) into the requirements is better (IMO).
您发布的建议实际上并没有告诉我要求是什么！取而代之的是，我现在必须弄清楚潜在意图必须是什么，才能得到想要的东西.换句话说，我必须逆向工程"预期的逻辑.这是传达要求的较差方法.实际上，这是交流复杂事物的一种较差方法.
Your posted suggestion actually doesn't tell me what the requirements are! Instead, I have to now figure out what the underlying intent must be in order to get what you're after. In other words, I have to "reverse engineer" the intended logic. That is a worse way to communicate requirements. In fact, it's a worse way to communicate anything complex.
这是对您发布的建议的一种解释
Here's one interpretation of your posted suggestion
Given a user who is not an admin
And products which are not active
When that user ever views any products
Then he cannot view the inactive products
Given a user who is an admin
And products which are not active
And products which are active
When that user ever views any products
Then he can view the both sets of products
但是，在您发布的建议中，应该允许非管理员查看无效产品吗?这是一个合理的问题.
However, in your posted suggestion, should the non-admin be allowed to view inactive products? This is a legitimate question.
如果您唯一说的是某某产品某某用途"，那么我不知道您是说所有权"还是可见度".如果我编写了允许所有用户查看其他人的产品的代码该怎么办?如果单击管理员用户配置文件，则会看到所有产品.如果单击非管理员用户配置文件，则只会看到活动的产品.看?我已经根据您的要求为每个用户成功地整理了清单.但是，如果您的意图是基于安全性的话，该怎么办！这样，非管理员甚至根本不会看到UI中存在的那些产品.这是一个非常不同的要求，但是您的文字并没有区分它.这是另一个很好的解释:如果您要我过滤的唯一东西是某种选择性"怎么办?即:我可以查看所有产品，但不能选择/附加/使用无效的产品(除非我是管理员).同样，这是对策展和可见度的不同解释.
If the only thing you say is that certain products are "for" so-and-so, then I don't know if you mean "ownership" or "viewability." What if I wrote code that allowed all users to view everyone else's products? If you click an admin user profile, you see all products. If you click on a non-admin user profile, you only see active products. See? I have successfully curated lists for each user according to your requirements. But what if your intent was security based! That somehow a non-admin should never even see those products existing in the UI at all. That is a very different requirement, but your writeup doesn't distinguish it. Here's another good interpretation: What if the only thing you're wanting me to filter is some kind of "selectibility"? ie: I can view all products, but I cannot select/attach/use inactive products (unless I'm an admin). Again, this is a different interpretation to curation and visibility.
您可能会说上下文"很明显.鉴于应用程序的页面流，没有人会误解其意图.但是，在看到足够多的程序进行了重大更改之后，您将根据上下文确定 not 的值，使事情变得显而易见".或者，有人只是将您的小黄瓜文件分成两部分.如果需要周围的要求来正确地解释这一要求，那么现在我们只需改善代码中的文件结构就可以了.
You might claim that "context" makes that obvious. Given the page flow of the app, no one's going to misunderstand the intent. However, after you see enough programs undergo major changes, you will value not depending on "context" to make things "obvious." Or what is someone merely splits your gherkin file into two parts. If surrounding requirements was necessary to interpret this one correctly, then now we've lost that simply by improving file structure in the code.
简而言之，沟通很困难.我相信将行为嵌入到需求中会减少人们误解它的机会.
In short, communication if figgin hard. I believe embedding behavior into the requirements decreases the chances that people will misinterpret it.
相反，此答案中的建议是字面上的.以后再添加或更改其他几层权限，或更改数据库模式都无所谓，我们知道这是什么要求.
In contrast, the suggestion in this answer is literal. It doesn't matter what other layers of permissions are added or changed later or how the DB schema changes, we know what the requirement is.
我认为以行为为导向的要求也可以帮助您更好地与产品所有者沟通.我敢打赌，产品负责人会说:我不希望其他人(除了管理员)能够看到无效的产品."我的建议几乎是逐字记录产品所有者在那种情况下会说些什么.您的建议必须将真正的意图转化"为程序员喜欢思考的数据驱动"视图.但是，我们越是将其注释转化"为不同的格式(如数据结构图)，我们承担风险的可能性就越大，并且误解.这样的翻译是有损的".在我们的职业生涯中，我们听到更多的时间是产品负责人说什么?我不是那样说的！"对于需求的隐式"沟通或过分"的翻译，我们会感到不舒服.相反，应明确声明每个文字要求.
I think behavior driven requirements helps you communicate with your product owner better too. I'm betting the product owner would say "I don't want anyone else (other than admins) being able to see inactive products." My suggestion is almost verbatim what the product owner would say in that case. Your suggestion has to "translate" the real intent to the "data-driven" view a programmer likes to think in. However, the more we "translate" their comments into different formats (like data structure diagrams) the more we risk assumptions and misunderstanding. Such translations are "lossy." The more times throughout our careers we hear our product owners say "what? That's not what I said!" the more we will feel uncomfortable with "implicit" communication or "obvious" translation of the requirements. Instead, explicitly state every single literal requirement.
根据我的经验，产品所有者总是首先考虑更多的行为/客户驱动术语.不过那只是我的经验.
In my experience, product owners always think in more behavior/customer-driven terms first. That's just my experience though.
Gherkin只是一种工具，所以它做的一件事和一件事都做得很好:它迫使您思考行为驱动的开发(BDD).如果使用小黄瓜，则必须按照输入"行为及其必需的结果来编写东西.否则，您将使用错误的工具.
Gherkin is merely a tool, so it does one thing and one thing well: it forces you to think in behavior driven development (BDD). If you use gherkin, you must write things in terms of "input" behavior and it's required outcomes. Otherwise you're using the wrong tool.
相反，您应该决定是否认为BDD是强迫自己遵循的良好哲学.如果您认为遵循这种哲学是好的，那么您将需要重新定义需求，直到出现何时"声明.某些人(包括我)认为强迫自己发表何时"声明的做法是件好事.
Instead, you should decide if you think BDD is a good philosophy to force yourself to follow. If you think following that philosophy is good, then you will need to keep rephrasing the requirement until there's a "when" statement. That exercise of forcing yourself to make a "when" statement is believed to be good by some (including me).
此外，小黄瓜并不与其他文档互斥.例如，您仍将拥有ERD图，UI模型等.实际上，您甚至可以从其他设计文档中引用小黄瓜方案. Gherkin旨在帮助您了解您是否在按照客户的要求进行操作，而不是您是否在设计代码方面做得很好.其他规范可以做到这一点，并且它们可以一起工作.
Also, gherkin is not mutually exclusive to other documentation. For example, you'll still have ERD diagrams, UI mockups, etc. In fact, you could even reference gherkin scenarios from within your other design docs. Gherkin is meant to help you know if you are doing what the customer asked, not if you are designing the code well. Other specs do that, and they work together.
不仅如此，需求"本身也具有层次，并以不同的方式表示.例如，您可能需要产品所有者为客户编写的签署"文档.该文档的格式与小黄瓜非常有所不同，因此是很好的.另一方面，您有一个ERD图.我认为小黄瓜是在需求抽象级别之间的中间".
Not only that, but "requirements" themselves have layers and are represented in different mediums. For example, you might need a "sign-off" document that the product owner writes up for the customer. The format of that document is very different than gherkin, and is good because of that. On the other extreme, you have an ERD diagram. I see gherkin as "in between" those levels of requirement abstraction.
此外，回归测试应该变得容易.有了小黄瓜，您甚至可以实现自动化.但是，再次，根据您发布的建议，我担心回归测试人员必须推断出并确定要测试的案例.这是进行回归测试的可怕方法.每一个案件都应清楚说明.即使对您显而易见"，我保证对其他人也不明显(反之亦然).另外，即使对于您自己，如果您必须进行回归测试，那么您也希望事情变得简单.回归测试压力越大，发生的可能性就越小，完成的效果就越差.拥有明确的清单可以减轻压力，并且易于遵循.行为驱动与回归测试非常吻合.
Also, regression testing should be made easy. With gherkin, you could even go so far as to automate it. Yet, again, with your posted suggestion I would fear that regression testers have to infer and figure out what cases to test. And that's a horrible way to do regression testing. Every single case should be spelled out. Even if it's "obvious" to you, I guarantee it's not obvious to others (and vice versa). Plus, even for yourself, if you have to do regression testing, then you want things to be easy. The more stressful regression testing is, the less likely it will happen and the less well it will be done. Having explicit checklists makes it less stressful and easier to follow. And being behavior driven aligns perfectly with regression testing.
这篇关于如何使用Gherkin根据授权测试过滤器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
