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.

基于STM32 F4的永磁同步电机无位置传感器控制策略研究内容概要:本文围绕基于STM32 F4的永磁同步电机(PMSM)无位置传感器控制策略展开研究,重点探讨在不依赖物理位置传感器的情况下,如何通过算法实现对电机转子位置和速度的精确估计与控制。文中结合嵌入式开发平台STM32 F4,采用如滑模观测器、扩展卡尔曼滤波或高频注入法等先进观测技术,实现对电机反电动势或磁链的估算,进而完成无传感器矢量控制(FOC)。同时,研究涵盖系统建模、控制算法设计、仿真验证(可能使用Simulink)以及在STM32硬件平台上的代码实现与调试,旨在提高电机控制系统的可靠性、降低成本并增强环境适应性。; 适合人群:具备一定电力电子、自动控制理论基础和嵌入式开发经验的电气工程、自动化及相关专业的研究生、科研人员及从事电机驱动开发的工程师。; 使用场景及目标:①掌握永磁同步电机无位置传感器控制的核心原理与实现方法;②学习如何在STM32平台上进行电机控制算法的移植与优化;③为开发高性能、低成本的电机驱动系统提供技术参考与实践指导。; 阅读建议:建议读者结合文中提到的控制理论、仿真模型与实际代码实现进行系统学习,有条件者应在实验平台上进行验证,重点关注观测器设计、参数整定及系统稳定性分析等关键环节。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值