Difference between revisions of "Cost Engine/Testing"
From ADempiere
This Wiki is read-only for reference purposes to avoid broken links.
(links) |
(→Test Plan) |
||
| Line 36: | Line 36: | ||
=Test Plan= | =Test Plan= | ||
| − | '' | + | ==Testing Framework Toolset== |
| + | *The [[TestFramework]] to be used is ''[http://fitnesse.org/FitNesse.UserGuide.FixtureCode Slim Fitnesse]''. | ||
| + | *''Decision Tables'' will send sample data and assertions to a ''Fixture'' that describes a ''Use Case'' that access a ''JUnit'' class testing the ''Cost Engine''. | ||
| + | *The ''Decision Tables'' are ''wiki-like'' where any user can edit the sample data. | ||
| + | *This allows maximum reuse, visibility, high readability and scenario building without editing JUnit classes. | ||
| + | |||
==Specifications and Document Review== | ==Specifications and Document Review== | ||
| + | ''Information gathering in progress. Please do not edit - [[User:Red1|Redhuan D. Oon]]'' | ||
This part answer the question whether there exist sufficient documentation of specifications for proper review and whether the codings are in accordance to [[ADempiere Best Practices]]. | This part answer the question whether there exist sufficient documentation of specifications for proper review and whether the codings are in accordance to [[ADempiere Best Practices]]. | ||
*Community Involvement - Yes | *Community Involvement - Yes | ||
| Line 58: | Line 64: | ||
==Use Cases== | ==Use Cases== | ||
| + | *Case I | ||
| + | *Case II | ||
| + | *Case III | ||
| + | *Case IV | ||
| + | *Case V | ||
| + | * ... | ||
===Black Box Testing=== | ===Black Box Testing=== | ||
| + | *Description of Use Cases that are common complete and quite comprehensive business scenario | ||
| + | |||
===Conditional Testing=== | ===Conditional Testing=== | ||
| + | *Specific tests that are white-box. They look into the code and ensure a certain loop condition is exhausted. | ||
| + | |||
==Issues Reference== | ==Issues Reference== | ||
* (link) | * (link) | ||
Revision as of 05:09, 11 January 2011
Introduction
- Testing is vital and crucial as software death can happen.
- We need to examine the overall compliance to our best practice besides going through the features, requirements and test plan.
- Then we examine the best tools for a test suite.
- Fitnesse is one such tool already explored by Carlos Ruiz and Ivan Calderon's team at Interopen.
- Fitnesse expands the concept of testing to be more bazaar like and allow anyone out there to test easily, diversely and constantly.
Scope Deliberation
To come to an understanding of a scope, it is best to grasp where we are and where we want to go.
General Proposition of an ERP
- The essence of a modern ERP today lies in its Financials Integration.
- The core of that is the Costing Engine that fulfills advanced Cost Accounting requirements.
- A Costing Engine is a highly challenging module to develop and even SAP cannot perfectly resolve all scenarios.
- ADempiere seeks to resolve the most common terms of advanced use, such as Average Costing with Average Invoicing, FiFO and LiFO.
State of Affairs
- Compiere, which ADempiere inherits from does not have a complete costing method beyond Standard Costing.
- In developing methods like Average Costing, e-Evolution has proposed that a complete writing of it is necessary.
- Thus the Sponsored Development: Libero Cost Engine is born.
Dictionary or Terms
- Costing Method - Standard, Average, FIFO, LIFO.
Index of Discussion Threads
(Listed in reverse chronology order - latest first)
Average Costing
- Mike Judd 2010-08-14
- Marek 2010-06-25
- Azzam Ahmad 2010-05-16
- Sanyasi 2008-02-13
- Armen Rizal 2007-06-15
- Joel S 2007-01-11
Standard Costing
Test Plan
Testing Framework Toolset
- The TestFramework to be used is Slim Fitnesse.
- Decision Tables will send sample data and assertions to a Fixture that describes a Use Case that access a JUnit class testing the Cost Engine.
- The Decision Tables are wiki-like where any user can edit the sample data.
- This allows maximum reuse, visibility, high readability and scenario building without editing JUnit classes.
Specifications and Document Review
Information gathering in progress. Please do not edit - Redhuan D. Oon This part answer the question whether there exist sufficient documentation of specifications for proper review and whether the codings are in accordance to ADempiere Best Practices.
- Community Involvement - Yes
- Discussion Thread - Yes
- Critical Need - Yes /as Feature /accounts impact
- Overlap with other branches - Yes: Armen, Carlos (according to discussion threads)
- Market Comparison - Existing standard
- Specifications Document - Yes, still pending review
- Versioning of Document - Not Visible, still pending review
- Testing Document - Not Visible, still pending review
- Review and Feedback - Not Entirely, still pending review
- Code Practice Compliance
- In-code documentation - pending review
- Code naming convention - Yes, still pending review
- Follow patterns - pending review
- Commit to Branch - Yes, still pending review
- Backward compatible - Core code changes /core model changes
- Impact to feature - Standard Costing
- Reference to Document Specs - Not Specific
Use Cases
- Case I
- Case II
- Case III
- Case IV
- Case V
- ...
Black Box Testing
- Description of Use Cases that are common complete and quite comprehensive business scenario
Conditional Testing
- Specific tests that are white-box. They look into the code and ensure a certain loop condition is exhausted.
Issues Reference
- (link)
Test Suite
You are invited
- If you wish to join in please sign with (*~~~) below.
