OpenSource ERP Software dedicated to small to mid-size companies

           Become Platinium or Gold Neogia Partner

Sub-menu developer :
General information :
Syntax :


Tools :
Modeling :

Best Practices

Contents

[edit]

Ofbiz code modification

Today, OfbizNeogia includes about 260 modified ofbiz files, knowing a synchronization needs between 4 and 5 hours of work to study and solve all conflicts caused by these files, I suggest you to respect the following Best Practices when you change an ofbiz file, so it could considerably decrease the dedicated time:

General rules:

Modification of existing code has to be done respecting the following formalisms, it's important to respect exact spelling, it's used to easier detect all modifications during ofbiz synchronization and they can help automatic programs to detect neogia modifications in ofbiz code.

in java: 

// Begin neogia specific : comment
/*
old code
*/
new code
// End neogia specific : comment


in xml: 

<!-- Begin neogia specific : comment -->
<!--
old code
-->
new code
<!-- End neogia specific : comment -->


in ftl: 

<#-- Begin neogia specific : comment -->
<#--
old code
-->
new code
<#-- End neogia specific : comment -->

We can automatically decrease the number of conflicts during synchronizations because the ofbiz code, which is in comment, is not changed.


WRONG WAY: 

<!-- old code -->
new code

In this case, a conflict can appear because the old code is modified 


<!-- Begin neogia specific : comment
old code
End neogia specific : comment -->

Problems of rereading occur with this format of comments 


<!-- Begin neogia specific : FR127343 -->
<!--
old code
-->
new code
<!-- End neogia specific : FR127343 -->

Tracker # is not sufficient. During the synchronization, we do not have time (to waste) to go on the Sourceforge site, searching for the modification purpose.

The comment 'comment' has to correspond to the title of the task ; it may contain the tracker # to obtain more information.

If the number of modifications brought into a file becomes too important, realize a fork could be a solution instead of following Ofbiz evolutions.

[edit]

UML diagrams modifications

UML diagrams are managed in Neogia cvs as binary files. As a result, it's impossible either to follow modifications brought in the model or to add modifications to these files in a branch.

  1. Modification of UML diagrams has to be always done in HEAD
  2. After a diagram modification, the code has to be refresh in HEAD in order to maintain the model consistency with the generated code


[edit]

Debug messages

[edit]

Messages Level 

 if (Debug.verboseOn()) Debug.logVerbose(message, module);
[edit]

Task realizations & Wiki

Documentation pages of the Wiki have to be filled during tasks realization, soon it will be imperative, unless the task won't be validated on Head.

There are two pages where documentation has to be put:

[edit]

Technical Manual

Concerns analysis or realization. Everything written during analysis or realization (so, Technical) has to be noted in Documentation/Technical Manual/{sub-component where modification is situated}. If possible, make a final review just before the task program run in TBT (To Be Tested), in order to get something correct (e. g.: delete rejected what-if)

[edit]

Functional Manual

Just before the task program run in TBT, this documentation has to be filled ; it must be done for users (consultants who know functional points). It may include test procedure of the function (it's the best way to explain it), or a detail of the purpose of this functionality and its use.


[edit]

Writing functional test using Selenium

[edit]

Always reinitialize session at the begining of the test

  1. logout of the application to test
  2. fill username
  3. fill password
  4. select language
  5. submit login form

All the test MUST begin with something like this:

Example (begining of application/party/webapp/tests/TestCreatePerson.html) : 

<-- Begin of standard login procedure -->
<tr>
	<td>open</td>
	<td>/partymgr/control/logout</td>
	<td></td>
</tr>
<tr>
	<td>type</td>
	<td>USERNAME</td>
	<td>admin</td>
</tr>
<tr>
	<td>type</td>
	<td>PASSWORD</td>
	<td>ofbiz</td>
</tr>
<tr>
	<td>select</td>
	<td>locale</td>
	<td>value=en</td>
</tr>
<tr>
	<td>clickAndWait</td>
	<td>submitButton</td>
	<td></td>
</tr>
<!-- End of standard login procedure -->

for more information look in: selenium

[edit]

Always test the presence of error messages after an action

Most of the time it's necessary to add after the automatic selenium IDE add asserTitle 

<tr>
       <td>assertElementNotPresent</td>
       <td>//div[@class='errorMessage']</td>
       <td></td>
</tr>
[edit]

Always select dropdown by value and not by label

Use 

<tr>
	<td>select</td>
	<td>locale</td>
	<td>value=fr</td>
</tr>

instead of 

<tr>
	<td>select</td>
	<td>locale</td>
	<td>label=french</td>
</tr>

So test is not sensible to label changes.

[edit]

Use stable xpath expression

By default Selenium IDE generates xpath expressions that depend of the page layout : 

//div/table/tbody/tr/td/table[1]/tbody/tr/td[2]/a

This kind of expression oblige us to review the expression each time the page layout change (column added/removed, row added/removed, etc). In most of the cases, it is possible to write xpath expressions that are independent of the layout by using conditions. Exemples:

Selection of a link by its href : 

//a[contains(@href, '/ordermgr/control/emptycart')]


[edit]

Files location

[edit]

Entity Models Definitions


[edit]

Services Definitions

[edit]

Screen-Widgets Definitions

[edit]

Form-Widgets Definitions

[edit]

Reports Definitions

Retrieved from "http://neogia.org/Best_Practices"