Dashboard

• Dashboards are graphical representations of reports. 
• Dashboards can be generated for summary or matrix reports (and not for tabular reports). 
• Dashboards display data as per the last time the report was run.
• A dashboard can have up to 20 components.

Dashboard Component Types

1. Chart
2. Gauge
3. Metric
4. Table
5. Visualforce Page
6. Custom S-Control

Data Source of Dashboard

1. Report
2. VisualForce Page

The chart in the Dashboard:

1. Vertical column
2. Horizontal bar
3. Line
4. Donut
5. Funnel
6. Pie

Important Points:

• Dashboard also support automatic refresh and email. The refresh and email can also be scheduled at intervals - daily, weekly, monthly.
• The folder in which dashboards are stored determines which user has access to running the dashboard. The dashboard data is based upon the reports data. When a user views the drill-down report for a dashboard component. running user's access permissions determine what data is displayed on the drilldown report. Hence it is possible that the data in the drill down report does not match the cumulative dashboard data.
• Dashboard also support automatic refresh and email. The refresh and email can also be scheduled at intervals - daily, weekly, monthly.
• Two things that determine access to dashboards: Dashboard Folder & Running User

Report

• A report returns a set of records that meets certain criteria and displays it in organized rows and columns. Report data can be filtered, grouped, and displayed graphically as a chart. Reports are stored in folders, which control who has access.
• In reports data displayed is as per running user's security access. Reports can be run on both standard and custom objects provided object must have permission for Report creation. Reports are stored in folders. Users with access to these folders can run the reports.
• Reports data is always generated in real-time. When a report is saved, reports configuration parameters are stored - but the generated data is not stored.

Types of Report:

1. Tabular report:  This is the most basic report. It displays just the row of records in a table-like format with grand total. Tabular reports cannot be used for generating dashboards.
2. Summary report: This is the most commonly type of report. It allows grouping of rows of data. It supports sorting and displaying subtotals. For example in a recruiting app, a summary report could be used to display open positions classified by department name.
3. Matrix report: Matrix report summarize information in a grid format. Matrix reports allows records to be grouped by both columns and rows.
4. Joint Report:Use the joined report format to create multiple views of the data contained in a single report. You can add multiple report types to a joined report, create standard and cross-block custom summary formulas, add a chart, and more.

Summary and Matrix reports can be used to generate dashboards.Report display upto 2000 rows of data. Larger reports can be emailed to Excel.

Report Type:

1. Standard Report Type:
1. Created when an object is created
2. Always inner joins
3. Cannot be modified.
4. Created when relationships between objects are created 
2. Custom Report type
1. Created by Admin or users with “Manager Custom Report types”.
2. Used to streamline the reporting process.

Use of bucket field in Reports in Salesforce:

• Bucket field in Reports in Salesforce is used to group values to the name we specify.
• Bucketing lets you quickly categorize report records without creating a formula or a custom field.
• When you create a bucket field, you define multiple categories (buckets) used to group report values.
• Custom reports let the developers define which all fields should be available in a report. Custom report allows user to change field names. Custom reports allow developers to select related fields (upto four levels). The custom reports also allow developers to add sections to group fields. Once a custom report is created it is available in reports tab and user may create reports from it.

Limitations of Salesforce reports:

• User Interface of Salesforce reports and dashboards is fixed. Salesforce does not support pixel perfect report.
• Salesforce reports do not support importing data from other sources
• When displaying objects and their children, Salesforce does not support reporting on objects that do not have any children.
• If an object has two different related lists, then Salesforce reporting does not support displaying both these related lists together.

Work-around these limitations,:

Salesforce customers have the following three options.

• Reporting as a service: Data resides on Salesforce. New Reports get generated from same data source
• BI as a service: Data is moved to a different destination on cloud. Reporting is performed on this new data server.
• Datawarehousing as a service: Data is exported to the customers server and reports are generated from the server located at the customers locations.
• Use VF Page for Complex Report

ETL Tools

ETL - Extract, Transform, Load: ETL is used to migrate data from one database to another, to form data marts and data warehouses, and also to convert databases from one format or type to another.

• ETL is short for extract, transform, load, three database functions that are combined into one tool to pull data out of one database and place it into another database.
• Extract is the process of reading data from a database.
• Transform is the process of converting the extracted data from its previous form into the form it needs to be in so that it can be placed into another database. Transformation occurs by using rules or lookup tables or by combining the data with other data.
• Load is the process of writing the data into the target database.

List of the most popular ETL tools:

• Informatica - Power Center
• Pervasive - Data Integrator
• IBM - Websphere DataStage(Formerly known as Ascential DataStage)
• SAP - BusinessObjects Data Integrator
• IBM - Cognos Data Manager (Formerly known as Cognos DecisionStream)
• Microsoft - SQL Server Integration Services
• Oracle - Data Integrator (Formerly known as Sunopsis Data Conductor)
• SAS - Data Integration Studio
• AB Initio
• Information Builders - Data Migrator
• Pentaho - Pentaho Data Integration
• Embarcadero Technologies - DT/Studio
• IKAN - ETL4ALL
• IBM - DB2 Warehouse Edition
• ETL Solutions Ltd. - Transformation Manager
• Group 1 Software (Sagent) - DataFlow
• Sybase - Data Integrated Suite ETL
• Talend - Talend Open Studio
• Expressor Software - Expressor Semantic Data Integration System
• Elixir - Elixir Repertoire
• OpenSys - CloverETL

Apex test Class

Unit testing is the software development practice of writing additional code, called unit tests. These tests execute your business logic code with known input parameters and evaluate the output for expected results.

What are the common facts for apex test Classes?

• isTest Annotation is used to define the Apex Test class.

• Classes defined with the isTest annotation do not count against your organization limit of 2 MB for all Apex code.

• Classes annotated with isTest can be declared as private or public otherwise Top-level type must have public or global visibility.

• At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.

• Every trigger must have some test coverage.

• All classes and triggers must compile successfully.

What are some Best Practices while writing Test Classes?

Whenever we are creating the test class, we must be following below best practices:

• Though we need 75% code coverage to deploy the class from Sandbox to Production, still test Coverage Target Should not be limited to 75%, we should try to make it 100%.

• If possible don’t use seeAllData=true, Create your Own Test Data.

• Create a Common class for Dummy Data for testing, and use it everywhere.

• If you’re Object’s Schema is not changing frequently, you can create a CSV file of records and load in a static resource. This file will act as Test data for your Test Classes.

• Use As much as Assertions like System.AssertEquals or System.AssertNotEquals to verify the test result.

• Use Test.startTest() to reset Governor limits in Test methods and close it with Test.stopTest().

• End your test class with “_Test”. So that in the Apex Class list view, the Main class and Test class will come together, resulting in easy navigation and time saver.

• Always test the Batch Capabilities of your code by passing 20 to 100 records.

• Use the runAs method to test your application in different user contexts.

• If there is a unique field then use System. currentTimeMillis() method with the name

• Test Negative scenario in the test class.

What are the methods used for test class?

1. Test.getStandardPricebookId() - Returns the ID of the standard price book in the organization.

2. Test.isRunningTest() -Returns true if the currently executing code was called by code contained in a test method, false otherwise. Use this method if you need to run different code depending on whether it was being called from a test.

3. Test.startTest()-Marks the point in your test code when your test actually begins. Use this method when you are testing governor limits.

4. Test.stopTest()-Marks the point in your test code when your test ends. Use this method in conjunction with the startTest method.

5. Test.loadData(Schema.SObjectType, String)-Inserts test records from the specified static resource .csv file and for the specified sObject type, and returns a list of the inserted sObjects.

Apart from the above, there are below methods used in Apex test Class:

1. System.Assert 

2. System.AssertEquals

3. System.AssertNotEquals

4. System.runAs(User)

What is the difference between System.Assert and System.AssertEquals()?

Basically, both methods are used to prove that code behaves properly.

System.Assert accepts two parameters, one (mandatory) which is the condition to test for, and the other a message (optional) to display should that condition be false.

Syntax:

System.assert(var1 == var2, "The value of var1 is: " +var1 + " and the value of... oh hell I don't care I mean it's just a variable");

System.AssertEquals and System.AssertNotEquals both accepts three parameters; the first two (mandatory) are the variables that will be tested for in/equality and the third (optional) is the message to display if the assert results in false.

Syntax:

System.assertEquals(var1, var2,<Optional Message>);

The advantage of System.AssertEquals over System.Assert is that the AssertEquals method shows the exact error without using the optional parameters. However, in the Assert method, we cannot be able to see the error until unless we will pass some message in the optional parameter.

To understand this, let's take an example, I am creating an Account in below two test classes. In one class, I am using the Assert method and in another class, I am using the assertEquals method.  

Test Class using AssertEquals 

Result 

When we will run the class, the below fail result will come. So, in this case, we don’t know what should be the result. 

How we create a fake response in the Test class?

Apex provides the built-in WebServiceMock interface and the Test.setMock method that you can use to receive fake responses in a test method.

How to write Test method of Controller Extension for StandardController?

Create the Object for which you are writing the Extension and pass the object instance in the ApexPages.StandardController as below: 

How to write Test method of Controller Extension for StandardSetController?

TestSetup Methods

Multiple test methods in the same class often have similar data requirements. Because of this, the Lightning Platform offers a way for you to annotate methods in your test class as @testSetup methods. The platform calls these methods automatically before every individual test method.

@isTest

private class myDataGenerationTests {

   @testSetup

   static void myDataGenerationTests() {

       List<sObject> accounts = Test.loadData(Account.SObjectType, 'Mock_Data');

   }

   @isTest

   static void testLoadAccountsFromStaticResource(){

       Test.startTest();

       List<Account> lstAccount =[Select Id from Account];

       Test.stopTest();

       system.assert(lstAccount.size() == 15, 'expected 15 accounts');

   }

}