Log in / create account
Openbravo.com
Issues
Forge
University
View source | Discuss this page | Page history | Printable version   

ERP 2.50:Developers Guide/Best Practices/Rules for avoiding Regressions

ERP 2.50:Developers Guide

Index


Contents

Overview

Purpose of this page is to list a number of rules, which if they are followed for all changes done, will avoid creating certain types of regression.

Whenever a new regression is found, a new rule will be added here to specifically avoid this type of regressions (where this is possible).

How to use this list

Ideally the developer/tester should keep this list in mind for every single commit he intends to do and if needed look up generic or specific rules again for the type of change he intends to do.

How to edit/improve this list

This page should not be edited directly, instead please use the Discussion page associated to it.

Accepted Rules

Rule #0: Make sure the regression does not reappear again

Description: Developer has to make sure that

  1. New test-cases are created or existing ones are modified in the Test Link that cover the regression.
  2. They are automated (if not there should be a clear to skip it)

Rule #1: Test all functional usage of the modified component

Rule #2: Don't let someone force you to create a regression

Description: Developer should be responsible for their changes and not allow anyone to force them to create a regression (if possible)

Rule #3: Look for any other usage of the changed piece of code/data

Description: For code searching might be using eclipse, in all cases a full-text search across all ERP should be done.

Rule #4: Do not skip any planned testing

Description: If a test case is planned to be done for some change, do not skip it

Rule #5: Check your diff before committing

Description: Always read/check your complete diff before committing. You need to verify that you know about and intend to do any line of change in there

Rule #6: Test all the changes you made

Description: If you need to do the same fix/change in several areas/files, you need to test each of those explicitly

Rule #7: Test INSERT/UPDATE/DELETE of a trigger

Description: When writing a trigger it is needed to execute your changed code at least once for all action the trigger is defined for (insert,update,delete) and do this on all supported databases

Rule #8: Consider maximum length restrictions

Description: If something you write to is length/size restricted (variables, database fields, html fields) your code needs to take care of this restriction. Especially the test plan should explicitly cover those corner-cases

Rule #8: For Build Validations and Module Scripts, test the install/update process

Description: A failing/crashing BuildValidation/ModuleScript does break the install and update process completely, which means doing an update (i.e. new module version) to fix this is not possible

Rule #9: Impact the smallest set of other code

Description: If you make a behaviour change, do it in a way which affects the smallest part of other code where possible. This makes testing 100% of the affected functionality easier.

Rule #10: Ask for help, provide help

Description: If you are not sure about a change, ask for help. If you have junior people in your team: Review all changes done by them

Rule #11: Check behaviour using only Tomcat and Apache+Tomcat in the stack

Description: If you make a change involving setting HTTP-response headers, you must test your change also with an Apache Server in front of the application server (Tomcat). In this case, behaviour of using only Tomcat and having Apache+Tomcat in the stack if different, so both deployment options need to be tested.

Rule #12: Test dbsourcemanager changes in all supported databases

Rule #13: Do development in a branch, merge to pi only when fully tested

Description: Every non-trivial development should be done in a branch which will be merged back into pi only when fully done and tested

Rule #14: Don't do huge projects/changes

Description: Changes affecting all of application should be avoided. If not possible to avoid, use branching and get some extra beta testing by customers.

Rule #15: Extra testing effort for Core changes

Description: Core changes which can affect behaviour of all existing code using this central piece need to be tested extra thoroughly

only after fixing a bug (correctly) the issue was raised (Now in "new" the call-out associated with the Organization field is triggered and makes this issue to show up)

Rule #16: If possible, reuse existing trigger

Description: If there is an existing trigger running at some point (i.e. insert,before) then add your change to this trigger instead of adding another trigger running at the same point (insert,before)

Rule #17: Triggers should run in any execution order

Description: You may not add a second trigger running ad the same moment (as another trigger) unless you make sure your new triggers works in any possible execution order among the set of triggers

Rule #18: Plan to test all the combinations

Description: When changing complex (black-box) components explicitly write-down all combinations which need to be tested. If possible automate this test

Proposed Rules

This list holds items, which need further analysis about exactly when and how the rule should be applied.

Languages: 

English | Translate this article... 


ERP 2.50:Developers Guide/Best Practices

Retrieved from "http://wiki.openbravo.com/wiki/ERP_2.50:Developers_Guide/Best_Practices/Rules_for_avoiding_Regressions"

This page has been accessed 8,076 times. This page was last modified on 8 May 2014, at 18:11. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.