In case you’ve missed our dev tips in past weeks, we will be posting them in the blog moving forward. To sign up and get your dev tips delivered to your inbox each week, click here!
Tip of the Week
Keep methods or functions as short and generic as possible. Not only will unit testing be easier, it will also make figuring out what that piece of code is supposed to be doing easier.
-
Classes should have one responsibility because you won’t remember all the stuff it does.
-
They should be named something meaningful to what it does.
-
They should have a limited number of they can do because… it should have only one responsibility.
-
-
Classes should not include methods that don’t describe what is the responsibility of that class. For instance, a Gateway ABAP Data Provider Class should provide data. But more often than not, you will see something like this that forces you to live inside the DPC_EXT class forever:
Here is an example of loading up a data provider class with business logic, that does not belong.
class ZCL_SALESORDER_DPC_EXT definition
public
inheriting from ZCL_SALESORDER_DPC
create public.
…. “ All of the fantastic generated code…
private section.
….
methods FIND_SOLD_TO_CUSTOMER
….
methods FIND_SHIP_TO_CUSTOMER
….
methods DO_PRICING_MAGIC
….
methods PRICING_IF_MAGIC_FAILS
….
methods ADD_PRICING_CONDITON
….
methods REMOVE_PRICING_CONDITION
….
methods COPY_SALES_DOC
….
methods CREATE_SALES_ORDER
….
methods FIND_SALES_ORDER
….
ENDCLASS.
A better example would be:
class ZCL_SALESORDER_DPC_EXT definition
public
inheriting from ZCL_SALESORDER_DPC
create public.
…. “ All of the fantastic generated code…
private section.
….
methods GET_CUSTOMERS
….
methods GET_MATERIALS
….
methods GET_SIMULATED_SALES_ORD
….
methods GET_SALESORDER_NUMBER
….
ENDCLASS.
THEN have classes for each object you’re trying to represent.
-
Methods or functions should be small and descriptive of purpose. This keeps code tight, easy to understand and easy to identify if a unit test fails.
//Example of a function that checks if an order is a simulation if there is an order number:
function isSalesOrderASimulation(sapOrderNumber) {
if(!sapOrderNumber) {
return true;
}
}
//Example of a corresponding unit test to verify that
describe(‘isSalesOrderASimulation’, function() {
it(‘should return true if the SAP Order number is blank, function() {
var sapOrderNumber = ”;
var result = isSalesOrderASimulation(sapOrderNumber);
expect(result).to.be.true;
});
});
