An inclusive unit test is one where you actively try to use the new code changes. For example if you added code that did something when an invoice was saved you would go through the process of saving an invoice. You should try as many permutations as seem relevant. For example if you were testing the amount of a fee at the time the invoice was saved you should save the invoice with lots of different fee amounts and types to ensure there are no defects in the new code.

An exclusive test is one where you test what happens when new code is not used, but related blocks of code are called. For example if you added code that was triggered by the user having a preference active you would have tested that code already with the inclusive unit testing. Now go back and disable the preference and repeat all the same test cases. This will ensure that you have not added any aberrant behavior when the code does not fire.

For all newly written code in Theatre Manager, the developer is expected to step through each line of code manually and verify the code is changing the variables as desired. If a code branch is not taken, the developer is expected to set up a condition to take that branch and prove that the values work, the notation is correct, the parameters are correct as designed. A developer is not expected to step through known to be working super class methods – those can be stepped over unless it produces an unexpected result.

With step through testing, you can quickly throw a lot of small tests at a bit of code. An example might be converting a number to text. Adjusting the input parameters and stepping over code to see the results can quickly test many different parameters.

Some segments of code are particularly vulnerable to security controls and/or breaches. This would represent the parts of code that touches credit card information or any of the web components.

Credit Card & Security Testing

NB: Make sure any testing uses only test cards and never use real credit cards in a non-production environment.

When altering any code that deals with credit card information, it is important that key tests are performed to ensure the software remains in PCI compliance. All security patches and system and software changes need to be tested before being deployed, including but not limited to testing for the following.

PA-DSS	Requirement	Testing Procedure	What we do in Theatre Manager
5.1.1.1	Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)	Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.)	When using the Theatre Manager application, input validation for almost all fields is done through the specialzed protected class called oEditCheck which does specialized validation on inputs. Every text input field in the system will invoke a method from this class. Test your code in the 'evAfter' clauses to make sure that it does for all entry fields. Since the Theatre Manager 'fat' client is a compliled application and not web based, much of this PCI requirement does not apply. The Theatre Manager commerce web server uses the same edit routines as the 'fat' client but has cleansing routines for parsing data prior to it hitting the edit routines. Refer to OWASP below.
5.1.1.2	Validation of proper error handling	Validation of proper error handling	particularly for credit card information, make sure that data is not diplayed back to an operator or customer that shows the entire PAN when errors occur. Refer to 5.1.1.5 for routines to display protected information appropriately.
5.1.1.3	Validation of secure cryptographic storage	Validation of secure cryptographic storage	all card information is updated in the database using a single protected classes called tfCreditCard.$reviseCreditCard. All access to cards is through that protected class and any use will ensure that cards are encrypted properly. However, after a test using credit cards, do an sql query on CD_CARD_NO to make sure nothing exists in clear text.
5.1.1.4	Validation of secure communications	Validation of secure communications	Card authorization occurs in via https and the merchant providerl. The protected classes oCCAuthorize handle all https communication and will not respond unless the merchant provider supports TLS 1.2 or later (high encryption)
5.1.1.5	Validation of proper role-based access control (RBAC)	Validation of proper role-based access control (RBAC)	Access to card information is managed in Theatre Manager through a protected class called oSecurity. All display of credit card information is done through another protected class called oEditCheck.$fetchCreditCard which converts all items for display using RBAC.

OWASP testing

For web based components (i.e oWebComxxx), ensure that OWASP vulnerabilities are also tested and verified per PA-DSS standards 5.2.1-5.2.10. This section in the PA-DSS document repeats the current top 10 OWASP vulnerabilities (circa 2010) and are repeated below. Make sure to test those as well as review OWASP to keep this section of the test requirements evergreen.

Above all, read the OWASP top 10 when developing a Web API because they explain clearly what things mean and strategies how to avoid.

PA-DSS	Requirement	Testing Procedure	What we do in Theatre Manager
5.2.1	Cross-site scripting (XSS).	Cross-site scripting (XSS) (Validate all parameters before inclusion.)	Look at any incoming parameters for javascript and other characters and simply removes them. We have determined that there is no valid need to have words like <script> in a enterable fields like name or address. Refer to rtWebSales.cleanUpParameters
5.2.2	Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws, as well as other injection flaws.	Injection flaws, particularly SQL injection (Validate input to verify user data cannot modify meaning of commands and queries.)	none of the API's in any oWebComXXX accept SQL for input. Make sure each parameter is checked for existance and validity using oWebComBase.$getWebParameters.
5.2.3	Malicious file execution	Malicious file execution (Validate input to verify application does not accept filenames or files from users.)	ensure that oWebComXXXX does not accept file names and does not read the file system. All input is sanitized and merged into variables of fixed length (the nature of Omnis Studio) so buffer overflows are not possible.
5.2.4	Insecure direct object references.	Insecure direct object references (Do not expose internal object references to users.)	OWASP recommends use of API's to address this issue. Build a new oWebComXXX for each web function.
5.2.5	Cross-site request forgery (CSRF).	Cross-site request forgery (CSRF) (Do not rely on authorization credentials and tokens automatically submitted by browsers.)	TM puts tokens in the cookie that are unique per session and per request.
5.2.6	Information leakage and improper error handling	Information leakage and improper error handling (Do not leak information via error messages or other means.)	ensure all messages are read from a table (tmError.txt) and only provide user direction, not system state.
5.2.7	Broken authentication and session management	Broken authentication and session management (Properly authenticate users and protect account credentials and session tokens.)	use the build in tCookie function to read and write cookies. Cookies are 3DES encrypted and contain time information to know if the patron is going back or forward. Requests that cannot be decrypted and have stale information are discared before they get to the oWebComXXX
5.2.8	Insecure cryptographic storage	Insecure cryptographic storage (Prevent cryptographic flaws).	make sure all internal keys and pw are never clear text in variables. Always store encrypted and use decryption to get the true value.
5.2.9	Insecure communications	Insecure communications (Properly encrypt all authenticated and sensitive communications.)	Implemented using TLS for the entire web site. Specific tokens like cookies and CC data are AES256 encrypted within the TLS layer. Always test for this.
5.2.10	Failure to restrict URL access.	Failure to restrict URL access (Consistently enforce access control in presentation layer and business logic for all URLs.)	All access to the web components are throught an API call. These are routed through a single apache module that adds some tokens of its own and redirects the URL to a specific machine, changes the IP and crosses a firewall from the DMZ using NAT. There is never direct access to any oWebComXXX