This document is aimed to summarize some basic use-cases for which CDAP is being used. Basic testing to be done from UI before creating a PR.

Functional Tests:

Use-Case - 1: How is a Purchase tracked and processed

This use-case skims through the dev section of the UI to test how a purchase history app is supposed to be used.

Testing Flow:

1. Deploy Purchase history app
2. Go to App's detailed view.
3. Go to Purchase Flow
4. Start the Flow 
5. Inject events into the stream of a flow from UI - Should show the count of events on stream flowlet.
6. See if the events flow through all the flowlets and reach the collector.
7. Stop the flow
8. Go to Datasets tab - Should show the datasets
9. Go to History - Should show the run history that we just started
10. Go to Purchases Datasets - Status page should show storage as few Bytes as we just added some streams
11. Go to explore tab and execute the default select * query. - Should show the results in the bottom section (events we injected)

GIF explaining the above steps: TestingFow

Testing Workflow/Mapreduce:

1. Go to PurchaseHistoryWorkflow
2. Start the Workflow - This should pick up the events injected into the stream of a flow
3. Mapreduce should run fine - initially having green border and once completed should be shaded with green indicating success
4. Click on the Mapreduce program to go the program and check its status - Should show status as completed and switching between mappers and reducers should show proper metrics
5. Hit back and it should come back to the workflow run view
6. Go to History Dataset - Same, the status page should show storage as few bytes.
7. Explore the dataset should show the history of purchases made by the user (Explore tab, execute query on the dataset).

GIF explaning the above steps: TestingWorkflowMR.gif

Testing Service:

Use-Case-1:

1. Go to PurchaseHistoryService and Start it.
2. Make a request to to /history/{customer} end point. - The customer is the same customer that we referred in our stream injection
3. Should show the list of purchases the user has made.

GIF explaning the above steps: TestingWorkflowMR.gif

Use-Case-2:

1. Go to UserProfileService and Start it.
2. Make a POST call to /user/{id} end point with the following JSON,

{

"id":"Alice",

"firstName":"Alice",

"lastName":"Bernard",

"categories":["fruits"]

}

       3. Go to flow and inject events in the name of Alice

       4. Go to PurchaseHistoryWorkflow and Start it and wait till it completes successfully.

       5. Go to PurchaseHistoryService again and make the same GET Request as we did above /user/{customer} - Here the customer would be Alice. 

       6. We should be able to see the User profile along with the purchase history information in the response.

GIF explaining the above steps: TestingService.gif

Testing Spark:

1. Deploy SparkPageRank app
2. Inject data by running /cdap/cdap-examples/SparkPageRank/bin/inject-data.sh (the script runs for a couple of minutes)
3. Start RanksService and TotalPagesPR
4. Go to SparkPageRankProgram
5. Click Start
6. You should see the metrics getting updated in the page
   

TODO: Add GIF

The above test makes sure Apps, Flows, Mapreduce, Service, Workflows, Datasets, Streams, Explorer work fine for base use-case.

Objective: Essentially what we are testing is -

We have a flow through which we can inject events - which then writes it to a dataset - a Workflow/Mapreduce will read from the dataset, process it and write it to another dataset - a Service helps us in viewing the data or we could do the same thing with explorer too. Here purchases dataset stores all purchases made by the user and history dataset stores the history of purchases made by the user.

Use-Case - 2: How an Adapter Works

Testing Adapter Creation: 

1.  Click "All Adapters" in Home page and Click the "+" sign to Create an Adapter
2. Choose the adapter type and enter a name for the adapter.

3. Setup Source - Stream Source 

   1. Give Stream Name
   2. Set Process Time Window to 1m
   3. Set Format to Text
   4. Set Schema to:
      1.  body (type string)
4. Setup Sink - TPFSAvro sink
   1. Give Dataset Name
   2. Set Schema to:
      1. ts (type long)
      2. body (type string)
5. Setup a Transform - Projection transform
   1. Fields to Drop: 
      1. headers
6. Schedule it for every 5 mins (If its ETLBatch adapter)
7. Publish the adapter.

This base case should work. If not something is wrong. The UI should say what is the error.

1. Once the adapter is created send events to the stream
2. Start the adapter now from the adapater list view /ns/default/adapters
3. Every 5 mins the dataset associated with the adapter should be injected with data we injected through our stream.
   1. Send some events to the stream you created
   2. Wait for 5 minutes
   3. Explore the dataset sink. You should see the events you sent to the stream

This is the basic use-case of an adapter. 

GIFs explaining the above steps: AdapterTest1.gif , TestingAdapter2.gif

Objective: The objective of this test is to see if an adapter can convert a stream that is of format csv to a TPFSAvro dataset that we use internally anywhere.

TODO: For metrics we need a basic test case to test.

Once the above mentioned steps work push the code two different clusters, secure and a non-secure cluster (beamer software install cluster_id cdap-ui - should take 5 mins to beam code to a cluster)

Once the cluster is up and running we should provide the cluster url and a gif of our test. This helps for the reviewer to assume that the feature/bug fix works and could start reviewing the code.

Behavioral Tests:

This is more of an open ended section where it depends on the user/developer to test their UI extensively. This needs more thought and automated tests to run.