5

We are aiming for 100% coverage for apex class.Some of the class has simple basic get;set; ,some with hardcode value.If we skip them, the code is not covered.

If the get set is complex contains query or calculation ,I can understand why it should be tested.But for simple get;set; just to generate dropdown in visualforce, is it worth to test ?Is system.assert still needed?How people normally test the get;set; ?Is it okay for aiming 100% code coverage in this case?

Example of code :

public List<SelectOption> getTimeOption(){

List<SelectOption> options = new List<SelectOption>();
            options.add(new SelectOption('Today','Today'));
            options.add(new SelectOption('Tomorrow','Tomorrow'));
            options.add(new SelectOption('Yesterday','Yesterday'));
            return options;
}

This is getter and setter that use in Visualforce.The test class is more than 75% without the portion above being covered.In this scenario, is it still best practice write the test class for code above.I know it can be write easily something like below, but I am not sure if 100% test class with system.assert for each method is ideal?

ctrl.getTimeOption();
//how i put system.assert on this?

The reason why I asked because I was being told that I should cover the setter getter code including with system.assert while IMHO I think it is not necessary because it does not run any special logic except just to display dropdown.Plus the code already more 75% covered on other portion that contains critical business logic.So I need to know the concrete answer ,and if it is required to aim for 100% with system.assert , please let me know how I should write system.assert for it.

  • Why do you have to skip it? Why are you hard coding values? – Adrian Larson Aug 8 '16 at 14:32
  • @AdrianLarson i update it with code.I need to know because there conflict between more 75% with critical code covered and must aim 100% with every single method should has system.assert. Which one is best practices? – unidha Aug 9 '16 at 3:12
2

For me there is only one reason to test basic getter/setter and that is if i'm around 75% test coverage in order to keep it above the limit. In cases where the coverage is between 90% and 100% i usually don't test basic getter/setter. It would just increase the time test cases takes to run.

3

Basically it's only for code-coverage purpose, I don't think it's really matters for real time testing..

Anyway you can easily test-cover it, if you're testing a controller you can create a controller instance in the test and call the fields directly from the ctrl instance. Like this:

MyPageCtrl ctrl = new MyPageCtrl();

ctrl.someField = <someValue>;
<fieldType> testField = ctrl.someField;

And if it's a ctrl extension you just need to pass a standard ctrl to you're ctrl's constructor.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.