ERP 2.50:Developers Guide/Best Practices/Rules for avoiding Regressions
ERP 2.50:Developers Guide |
|
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
- New test-cases are created or existing ones are modified in the Test Link that cover the regression.
- They are automated (if not there should be a clear to skip it)
- Example Regression: Issue 26469 is introduced although the same regression was fixed 2 months before it - issue 25569
Rule #1: Test all functional usage of the modified component
- Example Regression: Issue 13582 caused by issue 11481
- Intended change: Do not show the email icon in the toolbar, if window does not have the 'Send Email' capability
- Needed Testing:
- Email icon not shown in windows without email
- Email icon still shown in windows with email
- Cover all of possible ToolBar usages (WAD-window: grid/edit view, manual window (i.e. report)
- Example Regression: Issue 13650 caused by Enhanced preferences project
- Example Regression: Issue 13636 caused by issue 12225
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)
- Example Regression: Issue 13428 caused by issue 11438
- Regression was introduced intentionally to comply with the SLA for some defect
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.
- Example Regression: Issue 13284 caused by Build Validations and Module Scripts project
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
- Example Regression: Issue 13284 caused by Build Validations and Module Scripts project
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
- Example Regression: Issue 12982
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
- Example Regression: Issue 13357 caused by issue 12387
- Example Regression: Issue 12650 caused by issue 11977
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
- Example Regression: Issue 13356
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
- Example Regression: Issue 13175 caused by issue 12017
- Example Regression: Issue 13638 caused by Enhanced preferences project
- A new mandatory column was created for AD_Preferences table with a default value
- On create default wasn't created because it was though that with the definition of a default value in the column was enough
- But for tables that belongs to Application dictionary (AD tables) you still need to add the rule On create default
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
- Example Regression: Issue 13172.
- In this case what the log tells you it is a warning but not acceptable (It could create a lot of noise). So technically speaking is not a regression but from an end user perspective it is because you didn't have those warnings but suddenly you have it
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
- Example Regression: Issue 13163 caused by issue 12366
- Example Regression: Issue 12834 caused by issue 12600
- Example Regression: Issue 13650 caused by Enhanced preferences project
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.
- Example Regression: Issue 12832 caused by Allow comma separator project
- Example Regression: Issue 12788 caused by Allow comma separator project
- Example Regression: Issue 11976 caused by issue 4512
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
- Example Regression: Issue 12313. Regression (but only from the end user perception). In fact this issue is raised because of this changeset. The changeset is correct but then it shows "wrong" code done in the past
- Example Regression: Issue 12700. Similar case to 12313. The error always existed but
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)
- Example Regression: Issue 12845
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
- The execution order of multiple triggers in Postgres is by name of the trigger (alphabetical)
- The execution order of multiple triggers in Oracle is undefined/random (unless some special keyword is used (not possible via dbsourcemanager)
- The following regressions caused by the same issue 12366
- Example Regression: Issue 12845
- Example Regression: Issue 12802
- Example Regression: Issue 12846
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
- Examples are changing behavior of DataGrid.js, AccountingServer
- Example Regression: Issue 12539 cause by issue 11652
Proposed Rules
- Replacement of a complex component should be done by duplicating (+extra testing) and later replacement
- Example Regression: Issue 12811
This list holds items, which need further analysis about exactly when and how the rule should be applied.
Languages: |
ERP 2.50:Developers Guide/Best Practices