Harness Test Automation
What is Harness Test Automation? The harness is a server-side testing framework. It is being used for testing the server-side functionalities. Cactus (Jakarta product for java server-side testing) is a simple open-source test framework used for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters,…), and harness is built over it. JUnit V/s Harness JUnit tests run in the same JVM as the test subject whereas Harness tests start in one JVM and are sent to the app server’s JVM to be run. The package is sent via HTTP to the redirector. The redirector then unpacks the information, finds the test class and method, and performs the test. How do the Cactus work? Cactus has a class called ServletTestCase and it has 3 functionalities. 1) beginXXXX(WebRequestwebRequest){ } 2) testXXXXX(){ } 3) endXXXXX(WebResponsewebResponse ){ } Begin() – Here parameters are added to a request. It is executed on the client side. eg): In login, we can add a username and password to webRequest. Test() – Here we call the respective actions to be tested. In this, we get the implicit objects like request, response, and session as well as the parameters that we pass via Testcases.xml which are added inbeginXXXX(). Here we call the respective actions to be tested, which return pass or fail based on assertions. It is executed on the server-side. End() – The values in the response from the action can be tested here. It is executed on the client side. We have extended ServletTestCase to our harness framework with a class called FrameworkServletTestCase. FrameworkServletTestCase has the functionalities to getconfiguration files, testcases etc. The FrameworkServletTestCase is further extended to another class called QAToolTestCase. QAToolTestCase has postAssertions() and preAssertions()functionalities, which form the basis of whether a test case passes or fails. Cactus is configured in its property file called cactus.properties. Parameters configured are – cactus.contextURL = http://localhost:8080/CServer cactus.servletRedirectorName = ServletRedirector cactus.enableLogging=true We need to add the servlet class and servlet-mapping in web.xml for ServletRedirecton <!– Cactus Servlet Redirector configuration –> <servlet> <servlet-name>ServletRedirector</servlet-name> <servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class> </servlet> <!– Cactus Servlet Redirector URL mapping –> <servlet-mapping> <servlet-name>ServletRedirector</servlet-name> <url-pattern>/ServletRedirector</url-pattern> </servlet-mapping> Test cases are configured in the testcasexmls, where the parameters to be passed are defined. Test cases can be broken into smaller units called Snippets. These snippets are called fromTestCases.xml. Have questions? Contact the software testing experts at InApp to learn more.
Introduction to Exploratory Testing
Introduction to Exploratory Testing With this procedure, you will walk through the product, find out what it is, and test it. This approach to testing is called exploratory because you test while you explore. Exploratory testing is an interactive test process. It is a free-form process in some ways and has much in common with informal approaches to testing that go by names like ad hoc testing, guerrilla testing, or intuitive testing. However, unlike traditional informal testing, this procedure consists of specific tasks, objectives, and deliverables that make it a systematic process. In operational terms, exploratory testing is an interactive process of concurrent product exploration, test design, and test execution. The outcome of an exploratory testing session is a set of notes about the product, failures found, and a concise record of how the product was tested. When practiced by trained testers, it yields consistently valuable and auditable results. The elements of exploratory testing are: Product Exploration: Discover and record the purposes and functions of the product, types of data processed, and areas of potential instability. Your ability to perform exploration depends upon your general understanding of technology, the information you have about the product and its intended users, and the amount of time you have to do the work. Test Design: Determine strategies for operating, observing, and evaluating the product. Test Execution: Operate the product, observe its behavior, and use that information to form hypotheses about how the product works. Heuristics: Heuristics are guidelines or rules of thumb that help you decide what to do. This procedure employs a number of heuristics that help you decide what should be tested and how to test it. Reviewable Results: Exploratory testing is a results-oriented process. It is finished once you have produced deliverables that meet the specified requirements. It’s especially important for the test results to be reviewable and defensible for certification. As the tester, you must be prepared to explain any aspect of your work to the Test Manager and show how it meets the requirements documented in the procedure. Have questions? Contact the software testing experts at InApp to learn more.