--[[----------------------------------------------------------------------------

KSLuaTestCaseTest.lua

--------------------------------------------------------------------------------

ADOBE CONFIDENTIAL
------------------
Copyright 2010 Adobe Systems Incorporated
All Rights Reserved.

NOTICE: All information contained herein is, and remain the property of
Adobe Systems Incorporated and its suppliers, if any. The intellectual and
technical concepts contained herein are proprietary to Adobe Systems
Incorporated and its suppliers and may be covered by U.S. and Foreign
Patents, patents in process, and are protected by trade secret or copyright
law.  Dissemination of this information or reproduction of this material is
strictly forbidden unless prior written permission is obtained from
Adobe Systems Incorporated.

--------------------------------------------------------------------------------

This file serves as the canonical example of what a Lua-based test file should
look like. Please don't be intimidated by the size of it. Most of what's here
can be omitted safely in most cases (or are comments), so a "typical" test case
file will start off with a much smaller skeleton.

FILE NAME REQUIREMENT: Test case files must be named "(something)Test.lua" and
may be located anywhere in the build tree where native source files are typically
located (currently core and ios trees). The build system will include *Test.lua
files in the unit test app and omit them from the normal app build. By convention,
the (something) should match the Lua file (if any) that it is testing, and should
be located in the same directory.

WARNING: This file name (minus the .lua suffix) MUST NOT have the same name as
any Objective-C class in the app.

Each test case runs in its own Lua state which is destroyed immediately after
the test has completed.

The test case file is loaded and run twice: Once when the unit test app is launching,
and again when the test is performed. It should have no side effects other than
creating and returning the table that describes the test.

------------------------------------------------------------------------------]]

local KSLuaTestCaseTest = {}
	-- The result of running this file should be a single table with various
	-- members as described below. You may use any name and structure that
	-- achieves that result, but by convention, I suggest using the same name
	-- as the file to aid in interpreting search results.

local WFPlatformInfo = require 'WFPlatformInfo'

--------------------------------------------------------------------------------

function KSLuaTestCaseTest.setUpClass()
	-- The setUpClass function is optional. If present, it gets called before any
	-- other function in this test case file. It takes no parameters and any returned
	-- values are ignored.

	debug.print( "KSLuaTestCaseTest.setUpClass" )

end

--------------------------------------------------------------------------------

function KSLuaTestCaseTest.tearDownClass()
	-- The tearDownClass function is optional. If present, it gets called after all
	-- other functions in this test case file and immediately before the Lua state
	-- for this test class is destroyed. It takes no parameters and any returned
	-- values are ignored.

	debug.print( "KSLuaTestCaseTest.tearDownClass" )

end

--------------------------------------------------------------------------------

function KSLuaTestCaseTest.setUp()
	-- The setUp function is optional. If present, it gets called once for every
	-- test* function in this file, immediately before that function is called.
	-- It takes no parameters and any returned values are ignored.

	debug.print( "KSLuaTestCaseTest.setUp" )

end

--------------------------------------------------------------------------------

function KSLuaTestCaseTest.tearDown()
	-- The tearDown function is optional. If present, it gets called once for every
	-- test* function in this file, immediately after that function is called.
	-- It takes no parameters and any returned values are ignored.

	debug.print( "KSLuaTestCaseTest.setUp" )

end

--------------------------------------------------------------------------------

-- NOTE: Test functions must be named "test(something)". By convention, the (something)
-- should be in intercaps (starting with an initial cap). It must be a legal
-- identifier in C and Objective-C. Each of these functions will appear as a separate
-- entry in the unit test UI. The order of function execution is unspecified.
-- Test functions take no parameters and any returned values are ignored. Test
-- failure should be indicated by raising a Lua error.

-- The test cases in this file (i.e the functions that follow) are required only
-- for this particular test (KSLuaTestCaseTest.lua); they should be removed for any
-- other test and replaced with new test functions for that case.

--------------------------------------------------------------------------------

function KSLuaTestCaseTest.testDoNothing()

	-- As it says, do nothing. Native code checks to see that a test by this name
	-- exists in this test case and that it completes successfully.

end

--------------------------------------------------------------------------------

if not WFPlatformInfo.isAndroid then

-- We don't want to see this "expected failure" on Android.
function KSLuaTestCaseTest.testRaisedExceptionSpecialCase( test )

	-- [ arahn 05/09/2012 ] For Mac and iOS, the following notice applies:
	-- SPECIAL CASE ALERT: The native code has special-case code for this to
	-- verify that a Lua error gets converted into a unit test failure. See
	-- LuaTestCase_SelfTestSpecialCase; it looks for a unit test failure
	-- with the string "Expected failure" and converts that into unit test
	-- success.
	
	-- Do not copy this test into any other test case file.

	if WFPlatformInfo.isWindows then
		-- Notice [arahn 2012-05-08]: On Windows, we just tell the test
		-- that this is going to test failure.
		test:expectFailure()
	end
	
	error "Expected failure"

end

end

--------------------------------------------------------------------------------

function KSLuaTestCaseTest.testTraceback()

	debug.print( "Direct from Lua:" )
	debug.print( debug.traceback() )

	debug.print( "Single call:" )
	debug.printTraceback( "KSLuaTestCaseTest.testTraceback" )
	
end

--------------------------------------------------------------------------------

return KSLuaTestCaseTest
	-- As mentioned at the top of the file, the expected result of running a test
	-- case file is a single table describing the test case. Here we simply return
	-- the table that we've been building up throughout the file.
