FitnesseSlim

From ADempiere
Revision as of 22:03, 13 January 2011 by Red1 (Talk) (SourceCode)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
Note.gif Note:

I am using Fitnesse Slim to upgrade TestFramework. Expect more updates from time to time. Participants are welcome. - Redhuan D. Oon

Wiki page with data to trigger setters and methods in ADempiereLogin.java - POC upgraded with Slim version of Fitnesse

Background

java -jar fitnesse.jar -p 8080
  • .. you are ready to go!

WikiText

  • From the Frontpage at your
http://localhost:8080/ 
  • You can edit the FrontPage and create a sub-page i.e.
>LoginPage
  • This will then lead to a new page for you to edit. You can put in following text (edit the !paths to your local server occurrences):
!define TEST_SYSTEM {slim}
!path /Users/red1/Documents/workspace/FitnesseSlim/bin
!path /Users/red1/Documents/projects/Fitnesse/fitnesse.jar
!path /Applications/Adempiere/lib/Adempiere.jar
!path /Applications/Adempiere/lib/AdempiereCLib.jar

|import|
|fit|

!|ADempiere Login                                 |
|User     |Password|Client|ClientID?|Role|execute?|
|SuperUser|System  |System|$p=      |0   |true    |
|SuperUser|System|GardenWorld|$p=      |102 |true    |
|GardenAdmin|GardenAdmin|GardenWorld|$p=      |0 |true    |
|GardenAdmin|GardenAdmin|GardenWorld|$p=      |102 |true    |
|SuperUser|System|GardenWorld|$p=      |0 |true    |
  • On saving the page should look as shown at the top.

POC for ADempiereLogin

Purposely made wrong asserts to prove that the Test Engine really works.
A successful POC Login with easy user data to test true/false conditions. Just hit the Test button and get it intuitively on the same/single page.
  • I reused CarlosRuiz's code and refactored them:
    • r14692 /FitnesseSlim/src/fit/ (ADempiereLogin.java ModelLogin.java): Refactored ADempiereLogin as Fitnesse Fixture should not contain logic code but just Fixture data
    • r14693 /FitnesseSlim/src/fit/ (ADempiereLogin.java ModelLogin.java): Fixture should not produce output, just true/false or assert types for Fitnesse final result.
    • r14694 /FitnesseSlim/src/fit/ADempiereLogin.java: Fixture parse wiki input to be free from needing to put in @Ref tags, as column corresponds directly to Setter in java.
  • Tests are easily setup and the results are easily read:

Developer Notes

WikiPage

  • The title label at the top of the table is used to look for the java class in your path bin.
    • i.e. ADempiere Login will look for ADempiereLogin.class. The words are automatically joined.
  • Fitnesse can work as a Suite where multiple classes with respective tables point to a single Suite Page, with Teardown at the end of it.
    • Imports and Paths are then setup only once in the main suite page.
  • The use of a simple multi-row decision table as above allows quick formulating of testing data and its handling in code.
  • Each column title acts as either a property setter (Client) or a method (ClientID?). This is highly intuitive to a java coder.
  • An ordinary label such as 'Client' will look for its setClient(String Client) method.
    • As a setter allows me to obviously put any string parser at that setter method without asking again what that column type is.
    • Each column will have its own setter method.
  • To do something but not as a setter, then use a ?.
    • By putting a question mark after a label, it will look for a method with the same word. I.e. 'ClientID?' will look for ClientID() method.
    • It will post its return in the field space if a qualifier is present i.e. $P=.
    • This way we can return values from the test easily and quickly.
  • As seen above, paths are put in the wikipage content to ensure the ADempiere jars are within its classpath during execution.
  • There is no need to follow (in my case) the geneJar.desc instruction from Sunny at TestFramework, as just pathing to ADempiere jar is sufficient.
  • Sometimes Fitnesse intermittently misbehaves where new pages cannot be created or Debugger not triggering the breaks. It takes all sorts of restarting or test pages to get a feel of it. I suspect that too many clumsy edits may cause issues but once resolved they mysteriously do not recur.

SourceCode

  • A big thanks to CarlosRuiz for the bulk of the gruntwork in making a proper testing code.
  • The tests were trying to see which login info goes with which Role ID.
  • Upon testing and debugging, i noted in my refactored code that the ADempiereInstance happens only once. This saves time for repeating rows to test.
    • I ensured this by refactoring it into a superclass constructor:
	public ModelLogin() {
		if (adempiereInstance == null) {
			adempiereInstance = StaticAdempiereInstance.getInstance();
		}
	}
  • Furthermore the code (done by Carlos) already checks for different login info before relogin again.
		//Share login between different sessions
		if (   m_ads != null
			&& m_ads.isLoggedIn()
			&& m_ads.getM_AD_Client_ID() == m_client_id
			&& m_ads.getM_AD_Org_ID() == m_org_id
			&& m_ads.getAD_Role_ID() == m_role_id
			&& m_ads.getM_Warehouse_ID() == m_warehouse_id
			&& m_ads.getUser().equals(m_user)
			)
			return true; // already logged with same data