是在一行中指定给定的所有参数更好,还是在单独的行上指定每个参数更好?

发布于 2024-09-08 20:06:02 字数 1602 浏览 0 评论 0原文

是在一行中指定给定的所有参数更好,还是在单独的行上指定每个参数更好?即哪个更好?

单独并为每个参数

Scenario: some random scenario
 Given a menu with a menu width of 19 
 And quit text of "quit" 
 And Fruit options of 
  |Text|
     |some text|
     When ...
     Then ...

或特定给定的所有参数在一行

Scenario: Some scenario
 Given a menu with  quit text of "quit" and menu width of 19 and Fruit options of 
  |Text|
     |Some text|
    When ... 
 Then ...

这似乎(我希望我是错的)对您的编写方式有以下影响您的绑定,以及开始影响您编写类的方式,但它不应该!即第一个选项(每个参数单独 AND )如果您的类具有在创建对象后逐个设置的公共属性,则绑定更容易编写...

private Menu _menu;
[Given(@"a menu of fruit options")]
public void GivenAMenuOfFruitOptions(Table table)
{
    string[] fruitOptions = table.GetColumn("Fruit");
    _menu = new Menu(fruitOptions,null);
}

[Given(@"a menu width of (.*)")]
public void GivenAMenuWidthOf(string width)
{
    _menu.Width = int.Parse(width);
}

[Given(@"a Quite text of ""(.*)""")]
public void GivenAMenuWidthOf(string quitText)
{
    _menu.QuitText = quitText;
}

而选项二(全部在一行上)更容易拥有一个具有构造函数的对象,该构造函数将所有参数作为构造函数参数。

private Menu _menu;
[Given(@"a menu with  quit text of ""(.*)"" and menu width of (\d+) and Fruit options of ")]
public void GivenAMenuOfFruitOptions(string quitText, int width, Table table)
{
    string[] fruitOptions = table.GetColumn("Fruit");
    _menu = new Menu(fruitOptions,width, quitText);
}

我觉得好像我错过了一些东西,因为specflow的实现不应该影响我编写的代码,而且我担心上面的#1会鼓励过度有状态的对象。我是一个功能性的无国籍瘾君子。

任何指示都会非常有帮助。

提前发送,

干杯,艾伦

Is it better to specify all the parameters of a given in one line, or each parameter on a seperate line? i.e. which is better?

seperate And for each parameter

Scenario: some random scenario
 Given a menu with a menu width of 19 
 And quit text of "quit" 
 And Fruit options of 
  |Text|
     |some text|
     When ...
     Then ...

or all the paremters for the specific Given on one line

Scenario: Some scenario
 Given a menu with  quit text of "quit" and menu width of 19 and Fruit options of 
  |Text|
     |Some text|
    When ... 
 Then ...

This appears (and I hope I'm wrong) to have the following implications for how you write your bindings, as well as starts to influence how you write your class, which it shouldnt! i.e. first option (seperate AND for each parameter ) the binding is easier to write if your class has public properties that are set one by one after the object is created...

private Menu _menu;
[Given(@"a menu of fruit options")]
public void GivenAMenuOfFruitOptions(Table table)
{
    string[] fruitOptions = table.GetColumn("Fruit");
    _menu = new Menu(fruitOptions,null);
}

[Given(@"a menu width of (.*)")]
public void GivenAMenuWidthOf(string width)
{
    _menu.Width = int.Parse(width);
}

[Given(@"a Quite text of ""(.*)""")]
public void GivenAMenuWidthOf(string quitText)
{
    _menu.QuitText = quitText;
}

whereas option two ( all on one line) it's easier to have an object with a constructor that takes all the parameters as constructor arguments.

private Menu _menu;
[Given(@"a menu with  quit text of ""(.*)"" and menu width of (\d+) and Fruit options of ")]
public void GivenAMenuOfFruitOptions(string quitText, int width, Table table)
{
    string[] fruitOptions = table.GetColumn("Fruit");
    _menu = new Menu(fruitOptions,width, quitText);
}

I feel as if I'm missing something, because the implementation of specflow should not influence the code I write, and I'm worried that #1 above will encourage overly stateful objects. I'm a functional stateless addict.

Any pointers will be most helpful.

txs in advance,

cheers, Alan

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

洋洋洒洒 2024-09-15 20:06:03

我正在编写 BDD 样式测试,并且使用第一种方法,因为...

  1. 设置方法(也用于验证)可能会在相关测试中重用。
  2. 任何失败的测试都会突出显示失败的确切方法,包括设置。
  3. 消除了相关测试的重复,因此更容易维护。

I am writing BDD style tests and I am using the first method because...

  1. The setup methods (also for verification) might get reused in related tests.
  2. Any failing tests will highlight the exact method that fails, including setup.
  3. Eliminates duplication for related tests and thus will be easier to maintain.
魂归处 2024-09-15 20:06:03

不回答完整的问题,只回答这一部分:

我感觉好像失去了什么
因为specflow的实现
不应该影响我写的代码,
我担心上面的#1会
鼓励过度有状态的对象。我是
一个功能性的无国籍瘾君子。

我不认为场景的制定影响绑定代码是一个问题。这就是为什么它是一个绑定(其他框架称其为“胶水”,这更加强调了这一点)。您可以拥有设计良好的业务或自动化逻辑,必须使用绑定代码来驱动它们。

功能/无状态:步骤绑定没有内置链接选项(绑定方法返回下一个接收的内容),但您可以创建一种步骤上下文类(使用上下文注入:http://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ContextInjection/ )您可以在其中实现类似的设计。

Not answering the full question, but just this part:

I feel as if I'm missing something,
because the implementation of specflow
should not influence the code I write,
and I'm worried that #1 above will
encourage overly stateful objects. I'm
a functional stateless addict.

I don't think that it is a problem that the formulation of the scenarios influence the binding code. That's why it is a binding (other frameworks call it "glue" that emphasizes this even more). You can have a well designed business or automation logic that you have to drive with the binding code.

Functional/stateless: There is no built-in chaining option for the step bindings (the binding method returns something that the next receives), but you can create a kind of step context class (using context injection: http://github.com/techtalk/SpecFlow/tree/master/Tests/FeatureTests/ContextInjection/) where you can achieve a similar design.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文