I am having a design problem in test automation:-
我在测试自动化中遇到了设计问题: -
Requirements - Need to test different servers (using unix console and not GUI) through automation framework. Tests which I'm going to run - Unit, System, Integration
要求 - 需要通过自动化框架测试不同的服务器(使用unix控制台而不是GUI)。测试我将要运行 - 单元,系统,集成
Question: While designing a test case, I am thinking that a Test Case should be a part of a test suite (test suite is a class), just as we have in Python's pyunit framework. But, should we keep test cases as functions for a scalable automation framework or should be keep test cases as separate classes(each having their own setup, run and teardown methods) ? From automation perspective, Is the idea of having a test case as a class more scalable, maintainable or as a function?
问题:在设计测试用例时,我认为测试用例应该是测试套件的一部分(测试套件是一个类),就像我们在Python的pyunit框架中一样。但是,我们应该将测试用例保留为可扩展自动化框架的功能,还是应该将测试用例保持为单独的类(每个类都有自己的设置,运行和拆卸方法)?从自动化的角度来看,将测试用例作为一个类更具可扩展性,可维护性还是作为一个函数?
2 个解决方案
#1
0
Normally Test Cases are used as classes rather than functions because each test case has own setup data and initialization mechanism. Implementing test cases as a single function will not only make difficult to set up test data before running any test case, but yes you can have different test method in a test case class if you are running same test scenario.
通常,测试用例用作类而不是函数,因为每个测试用例都有自己的设置数据和初始化机制。将测试用例实现为单个函数不仅难以在运行任何测试用例之前设置测试数据,而且如果运行相同的测试场景,则可以在测试用例类中使用不同的测试方法。
#2
0
The following is my opinion:
以下是我的意见:
Pros of writing tests as functions:
将测试编写为函数的优点:
- If you need any pre-requisites for that test case, just call another function which provides the pre-requisites. Do the same thing for teardown steps
- Looks simple for a new person in the team. Easy to undertstand what is happening by looking into tests as functions
如果您需要该测试用例的任何先决条件,只需调用另一个提供先决条件的函数。对拆卸步骤做同样的事情
对于团队中的新人来说看起来很简单。通过将测试视为功能,可以轻松应对所发生的事情
Cons of writing tests as functions:
将测试编写为函数的缺点:
-
Not maintainable - Because if there are huge number of tests where same kind of pre-requisites are required, the test case author has to maintain calling each pre-requisite function in the test case. Same for each teardown inside the test case
不可维护 - 因为如果有大量测试需要相同类型的先决条件,测试用例作者必须维持在测试用例中调用每个先决条件函数。测试用例内的每个拆解都是一样的
-
If there are so many calls to such a pre-requisite function inside many test cases, and if anything changes in the product functionality etc, you have to manually make efforts in many places again.
如果在许多测试用例中有如此多的调用这样的先决条件功能,并且如果产品功能有任何变化等,则必须在许多地方再次手动进行操作。
Pros of writing test cases as classes:
将测试用例编写为类的优点:
- Setup, run and teardown are clearly defined. the test pre-requisites are easily understood
- If there is Test 1 which is does something and the result of Test 1 is used as a setup pre-requisite in Test 2 and 3, its easy to just inherit from Test 1, and call its setup, run a teardown methods first, and then, continue your tests. This helps make the tests independent of each other. Here, you dont need to make efforts to maintain the actual calling of your code. It will be done implicitly because of inheritance.
- Sometimes, if the setup method of Test 1 and run method of Test 2 might become the pre-requisites of another Test 3. In that case, just inherit from both of Test 1 and Test 2 classes and in the Test 3's setup method, call the setup of Test 1 and run of Test 2. Again you dont need to need to maintain the calling of the actual code, because you are calling the setup and run methods, which are tried and tested from the framework perspective.
设置,运行和拆卸都有明确的定义。测试的先决条件很容易理解
如果测试1做了某些事情并且测试1的结果被用作测试2和3中的设置先决条件,那么它很容易从测试1继承并调用其设置,首先运行拆解方法,并且然后,继续你的测试。这有助于使测试彼此独立。在这里,您不需要努力维护代码的实际调用。由于继承,它将隐式完成。
有时,如果测试1的设置方法和测试2的运行方法可能成为另一个测试3的先决条件。在这种情况下,只需继承测试1和测试2类,并在测试3的设置方法中调用测试1的设置和测试2的运行。再次,您不需要维护实际代码的调用,因为您正在调用设置和运行方法,这些方法是从框架角度进行尝试和测试的。
Cons of writing test case as classes:
编写测试用例作为类的缺点:
- When the number of tests increase, you cant look into a particular test and say what it does, because it may have inherited so much levels that you cant back track. But, there is a solution around it - Write doc strings in each setup, run, teardown method of each test case. And, write a custom wrapper to generate doc strings for each test case. While/After inheriting, you should provide an option to add/Remove the docstring of a particular function (setup, run, teardown) to the inherited function. This way, you can just run that wrapper and get information about a test case from its doc-strings
当测试次数增加时,您无法查看特定测试并说出它的作用,因为它可能已经继承了很多级别而无法回溯。但是,有一个解决方案 - 在每个测试用例的每个设置,运行,拆解方法中编写doc字符串。并且,编写自定义包装器以为每个测试用例生成doc字符串。在继承/继承之后,您应该提供一个选项来添加/删除特定函数(设置,运行,拆卸)的文档字符串到继承的函数。这样,您就可以运行该包装器并从其doc-strings获取有关测试用例的信息
#1
0
Normally Test Cases are used as classes rather than functions because each test case has own setup data and initialization mechanism. Implementing test cases as a single function will not only make difficult to set up test data before running any test case, but yes you can have different test method in a test case class if you are running same test scenario.
通常,测试用例用作类而不是函数,因为每个测试用例都有自己的设置数据和初始化机制。将测试用例实现为单个函数不仅难以在运行任何测试用例之前设置测试数据,而且如果运行相同的测试场景,则可以在测试用例类中使用不同的测试方法。
#2
0
The following is my opinion:
以下是我的意见:
Pros of writing tests as functions:
将测试编写为函数的优点:
- If you need any pre-requisites for that test case, just call another function which provides the pre-requisites. Do the same thing for teardown steps
- Looks simple for a new person in the team. Easy to undertstand what is happening by looking into tests as functions
如果您需要该测试用例的任何先决条件,只需调用另一个提供先决条件的函数。对拆卸步骤做同样的事情
对于团队中的新人来说看起来很简单。通过将测试视为功能,可以轻松应对所发生的事情
Cons of writing tests as functions:
将测试编写为函数的缺点:
-
Not maintainable - Because if there are huge number of tests where same kind of pre-requisites are required, the test case author has to maintain calling each pre-requisite function in the test case. Same for each teardown inside the test case
不可维护 - 因为如果有大量测试需要相同类型的先决条件,测试用例作者必须维持在测试用例中调用每个先决条件函数。测试用例内的每个拆解都是一样的
-
If there are so many calls to such a pre-requisite function inside many test cases, and if anything changes in the product functionality etc, you have to manually make efforts in many places again.
如果在许多测试用例中有如此多的调用这样的先决条件功能,并且如果产品功能有任何变化等,则必须在许多地方再次手动进行操作。
Pros of writing test cases as classes:
将测试用例编写为类的优点:
- Setup, run and teardown are clearly defined. the test pre-requisites are easily understood
- If there is Test 1 which is does something and the result of Test 1 is used as a setup pre-requisite in Test 2 and 3, its easy to just inherit from Test 1, and call its setup, run a teardown methods first, and then, continue your tests. This helps make the tests independent of each other. Here, you dont need to make efforts to maintain the actual calling of your code. It will be done implicitly because of inheritance.
- Sometimes, if the setup method of Test 1 and run method of Test 2 might become the pre-requisites of another Test 3. In that case, just inherit from both of Test 1 and Test 2 classes and in the Test 3's setup method, call the setup of Test 1 and run of Test 2. Again you dont need to need to maintain the calling of the actual code, because you are calling the setup and run methods, which are tried and tested from the framework perspective.
设置,运行和拆卸都有明确的定义。测试的先决条件很容易理解
如果测试1做了某些事情并且测试1的结果被用作测试2和3中的设置先决条件,那么它很容易从测试1继承并调用其设置,首先运行拆解方法,并且然后,继续你的测试。这有助于使测试彼此独立。在这里,您不需要努力维护代码的实际调用。由于继承,它将隐式完成。
有时,如果测试1的设置方法和测试2的运行方法可能成为另一个测试3的先决条件。在这种情况下,只需继承测试1和测试2类,并在测试3的设置方法中调用测试1的设置和测试2的运行。再次,您不需要维护实际代码的调用,因为您正在调用设置和运行方法,这些方法是从框架角度进行尝试和测试的。
Cons of writing test case as classes:
编写测试用例作为类的缺点:
- When the number of tests increase, you cant look into a particular test and say what it does, because it may have inherited so much levels that you cant back track. But, there is a solution around it - Write doc strings in each setup, run, teardown method of each test case. And, write a custom wrapper to generate doc strings for each test case. While/After inheriting, you should provide an option to add/Remove the docstring of a particular function (setup, run, teardown) to the inherited function. This way, you can just run that wrapper and get information about a test case from its doc-strings
当测试次数增加时,您无法查看特定测试并说出它的作用,因为它可能已经继承了很多级别而无法回溯。但是,有一个解决方案 - 在每个测试用例的每个设置,运行,拆解方法中编写doc字符串。并且,编写自定义包装器以为每个测试用例生成doc字符串。在继承/继承之后,您应该提供一个选项来添加/删除特定函数(设置,运行,拆卸)的文档字符串到继承的函数。这样,您就可以运行该包装器并从其doc-strings获取有关测试用例的信息