Cost Engine/Testing

From ADempiere
Revision as of 04:28, 20 January 2011 by Red1 (Talk) (Specifications and Document Review)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
Cost Engine Test Suite based on Slim version of Fitnesse, designed as a Suite of Column Tables.

Introduction

The Column Table for iterating each transaction and asserting their costing results.
  • 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.
    • It is easily upgraded to SLIM, a more powerful version of Fitnesse. (See right)
    • Fitnesse can be run as a Suite where reusable statements are Setup appearing on a single page.

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

Constraints Environment

  • First we be asking questions such as:
  • Will the Web Ui be tested? Or is the Costing Engine merely confined to itself and not its performance over the web?
  • What will be the maximum type of Organisations encountered?
    • There can be about 4 basic organisations to represent each costing method:
  1. OrgStd - Organisation that uses Standard Costing
  2. OrgAve - Organisation that uses Average Costing
  3. OrgFif - Organisation that uses First In First Out Costing
  4. OrgLif - Organisation that uses Last In First Out Costing
  • When are the other branches or vertical projects that have impact or vice versa?
  • What are the parts that we will NOT be testing?
  • What will comprise a successful testing and how will the results be presented or documented?
  • Who can be the independent testers and what tools can they use?
  • How will testers use the same tools and deal with different set of data or results?
  • What will be weakness or caveat of the tools used?

Dictionary or Terms

  • Costing Method - Standard, Average, FIFO, LIFO.

Index of Discussion Threads

(Listed in reverse chronology order - latest first)

Average Costing

Standard Costing

Test Plan

Testing Framework Toolset

First stage testing to setup Historical Data, asserting successful generation of Cost Transaction
  • 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.

Environment Setup

  • As shown in above screen, !paths are set to the latest Adempiere.jar and AdempiereClib.jar which was RUN_Setup with the LiberoCE.jar (renamed to customization.jar) and patches.jar in the ADempiereHome/lib folder.
    • Login to System and GardenAdmin to Run Role Access Update after that and you are ready to start the tests.
  • Other !paths are for Fitnesse/bin workspace which testing code is been developed and run, and fitnesse.jar in use.

Specifications and Document Review

POC of first row of test, Purchase and Receipt for 5 Oak at $36. Hard asserts are not used but dynamic output in grey are helpful enough.

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 : Single Organization with Seed DB
  • Case II: Single Organization with data in live environment.
  • Case III
  • Case IV
  • Case V
  • ...

Testing Criteria:Product Assets = Inventory Valuation Report ( except decimals by divide & multiply)

Account Info ( Product Assets & Each product ) = Transactions Valuation Report 
     = Statement of Accounts ( for Each Product )
For items purchased :Total purchasing amounts compared to total cost of goods sold.
Testing Cases :
 
           - Items without Landed Cost
           - Items With Cost
           - Foreign Currency Purchasing
           - Transactions on products with zero cost

 Testing Transactions ( Windows ):

          - Material Receipt
          - Shipment 
          - Internal Use Inventory
          - Physical Inventory.
          - Inventory Move.
          - Customer RMA
          - Vendor RMA

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.
  • Redhuan D. Oon :)

Links