Coding Standards and Best Practices for "appobjects" Files

本文介绍了AppObjects类文件的最佳实践,包括使用Javadoc注释、遵循统一的命名规范、利用ObjectGetter类包装器以及如何为每个类文件添加单元测试等。这些指南有助于提高代码的可维护性和一致性。

 1. Each test object getter in an appobjects class file should be properly commented with javadoc.

Tip: You can easily add javadoc to your code by placing the cursor on the top line of the method you want to javadoc and type /**<enter>. RFT will create a javadoc outline for you including parameters.

 

Standard appobject getter javadoc header (section in light blue text below):

/**
  * @return WButton for OK button in Add Folder page
  */

 public WButton getButton_OK() {

...

 }

 

The appobject class file should also have a javadoc header above the class statement that provides the name of the appobjects class file and describes what the class file is (see below):

/**
 * Class Name   : <b>Browser</b> <BR>
 * Generated     : Oct 1, 2003 4:26:21 PM <BR>
 * Description   : Web Browser Test Object Library <BR>
 * Original Host : WinNT Version 5.0  Build 2195 (Service Pack 4) <BR>
 *
 * @since  2007/10/01 <BR>
 * @author *<BR>
 */


public class Browser extends BrowserHelper
{

...


2. All appobject getters should use a ObjectGetter class wrapper:

There are several getter wrappers in the ObjectGetter class. One for almost every situation. If your situation is a rare special case that a standard wrapper will not work then you can create a custom object getter in your appobject file but this should only be used in special cases. Using the standard getters makes it easy to make global changes to all test objects by only having to modify code in one place. It also makes it easier to manage large projects with lots of test objects. Below is an example of a appobject getter method using a standard ObjectGetter class wrapper. Almost all appobject getters should like this:

 public WButton getButton_Cancel()
 {
  try{return new WButton(og.getNthObject(0,Webfuncs.gsTitleProp, new RegularExpression(".*Cancel.*", false), Webfuncs.gsClassProp, Webfuncs.gsHtmlBtnRef));}catch(Exception e){return null;}   
 }


3.  All appobject getter names should follow the following format:

get<class_type>_<DescriptiveObjectName>() where <class_type> is equal to one of the following:
 
WTextField = Text
WButton = Button
WListBox = List
WLink = Link
WCheckBox = CheckBox
WRadioButton = RadioButton
WTable = Table

 

There may be some special cases that do fall under one of these classtypes but these types should cover approximately 90% to 95% of all test object classes.

 

The <DescriptiveObjectName> should be a descriptive object name in "Proper" case format (each word in the descriptive object name is capitalized for easier identification i.e. MyDescriptiveObject).

 

For example, if I were naming the getter for the "Teamspace Name" text field object it would like this:

getText_TeamSpaceName()

 

4. appobject class files should have a unique name beginning with a capital letter (i.e. Applications.java)

The appobjects automation directory and any of it's subdirectories should be in all lower case characters (i.e. appobjects.administration.admin_console.users) but the appobjects class file name should begin with a capital letter.

 

5. All appobject class files should eventually contain unit tests.

You can easily add unit tests to your appobject file by running the unittest.UnitTestMain script on your appobjects class file.

1. For every appobject class file (i.e. SearchPage, Teamspace, etc. ) for which you want a unit test generated, make an entry in the UnitTestMain script's vector using "v.add" (i.e. v.add(new Teamspace());   )
2. Add import statements as necessary.
3. Check out your appobjects files if they are under source control.
4. Then execute the UnitTestMain script.

The UnitTestMain script will generate a unit test section in your script that looks like the following:

 

 public void testMain (Object[] args)
 {
  og.verifyGetter(getButton_Cancel(), "getButton_Cancel()");
  og.verifyGetter(getButton_OK(), "getButton_OK()");
  }

  

The unit test, when executed, will verify that all of the test objects in your appobjects class file exist on the current browser page and are identifiable by the automation.

 

6. Generally, all necessary external classes are instantiated at the top of an appobjects class file directly below the class statement.

See the placement of the Browser b = new Browser(); statement below. If all of our class files use this area of the script to instantiate other classes it will be easier to find object reference variables, etc.

 

7. As a rule the appobjects folder should contain only test object library files. These test object library files should contain only test object getter methods. The getter methods should do nothing but return an object.

 

8. appobject class files (or tasks files) should not reference/import testcases files.

 

appobjects and tasks files should never reference (import) testcases files. testcases files (Scripts) can and should import the necessary tasks and appobjects files but not vice-versa. A tasks or appobjects file that imports a testcases file will cause a compile error when removing the imported testcases file from the datastore. tasks and appobjects files should never import testcases files.

【完美复现】面向配电网韧性提升的移动储能预布局与动态调度策略【IEEE33节点】(Matlab代码实现)内容概要:本文介绍了基于IEEE33节点的配电网韧性提升方法,重点研究了移动储能系统的预布局与动态调度策略。通过Matlab代码实现,提出了一种结合预配置和动态调度的两阶段优化模型,旨在应对电网故障或极端事件时快速恢复供电能力。文中采用了多种智能优化算法(如PSO、MPSO、TACPSO、SOA、GA等)进行对比分析,验证所提策略的有效性和优越性。研究不仅关注移动储能单元的初始部署位置,还深入探讨其在故障发生后的动态路径规划与电力支援过程,从而全面提升配电网的韧性水平。; 适合人群:具备电力系统基础知识和Matlab编程能力的研究生、科研人员及从事智能电网、能源系统优化等相关领域的工程技术人员。; 使用场景及目标:①用于科研复现,特别是IEEE顶刊或SCI一区论文中关于配电网韧性、应急电源调度的研究;②支撑电力系统在灾害或故障条件下的恢复力优化设计,提升实际电网应对突发事件的能力;③为移动储能系统在智能配电网中的应用提供理论依据和技术支持。; 阅读建议:建议读者结合提供的Matlab代码逐模块分析,重点关注目标函数建模、约束条件设置以及智能算法的实现细节。同时推荐参考文中提及的MPS预配置与动态调度上下两部分,系统掌握完整的技术路线,并可通过替换不同算法或测试系统进一步拓展研究。
先看效果: https://pan.quark.cn/s/3756295eddc9 在C#软件开发过程中,DateTimePicker组件被视为一种常见且关键的构成部分,它为用户提供了图形化的途径来选取日期与时间。 此类控件多应用于需要用户输入日期或时间数据的场景,例如日程管理、订单管理或时间记录等情境。 针对这一主题,我们将细致研究DateTimePicker的操作方法、具备的功能以及相关的C#编程理念。 DateTimePicker控件是由.NET Framework所支持的一种界面组件,适用于在Windows Forms应用程序中部署。 在构建阶段,程序员能够通过调整属性来设定其视觉形态及运作模式,诸如设定日期的显示格式、是否展现时间选项、预设的初始值等。 在执行阶段,用户能够通过点击日历图标的下拉列表来选定日期,或是在文本区域直接键入日期信息,随后按下Tab键或回车键以确认所选定的内容。 在C#语言中,DateTime结构是处理日期与时间数据的核心,而DateTimePicker控件的值则表现为DateTime类型的实例。 用户能够借助`Value`属性来读取或设定用户所选择的日期与时间。 例如,以下代码片段展示了如何为DateTimePicker设定初始的日期值:```csharpDateTimePicker dateTimePicker = new DateTimePicker();dateTimePicker.Value = DateTime.Now;```再者,DateTimePicker控件还内置了事件响应机制,比如`ValueChanged`事件,当用户修改日期或时间时会自动激活。 开发者可以注册该事件以执行特定的功能,例如进行输入验证或更新关联的数据:``...
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值