Test Class Fraud – what’s my responsibility? [closed]

In doing some work for a client, I discovered a class that has 1500 lines (out of 2500) consisting entirely of

public static void AAA() {
        Decimal a = 0;
        a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;
        a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;
        a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;
        a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;
        a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;a++;

It is literally the only thing that gets tested by the test class. I’m notifying the client (who probably won’t be too fussed about it.) I’ll probably be asked to make a minor change to the Controller — 15 minutes work, maybe 30. Do I have any ethical responsibility to insist on legit test code and coverage? At this point, it wouldn’t surprise me if it took 10+ hours to develop legit test code for this controller, given the complexity of the requisite input data. Unfortunately the controller is written in a very procedural fashion, so it isn’t even possible to write code to test individual classes within it.

In addition to the requested moral counsel, I’d appreciate your ideas on how best to explain why this is important to the client. They have a CIO who is presumably quite tech savvy though not so familiar with Salesforce, and my direct contact is a new-ish admin.

Answer

The situation as I think I understand it is:

  • This public static void AAA() method is part of the controller that you’d be modifying
  • Its only purpose is to pad out the number of covered lines for the controller
  • So that the person who created it didn’t have to write a real test class to get it deployed

If my understanding is correct, then that’s a pretty underhanded approach that was taken (or if I’m feeling charitable, they weren’t a developer/were under an impossible deadline).

On your responsibility for testing

No good deed goes unpunished

This part of the question would probably be better for workplace.stackexchange.com. At the risk of sounding like I need to take a remedial software ethics course, I’m of the opinion that your ethical responsibility ends with you notifying your client about this issue and trying to convince them to have you rewrite the test class.

You found an unexpected problem in the course of doing the work you were hired/contracted for. It’s beyond terrible practice, but it isn’t causing things to break for your client and it won’t hinder your own work.

Communication is paramount here. Inform your client, present your case for what you think should be done, and then what you do next depends on how your client responds.

They could give you the ok to remove that garbage and make a proper test class, or they may decline (for money/time/lack of care/whatever). The worst scenario (in terms of politics/relationships) would be for your client to expect to be billed for 30 minutes of work, and then you bill them for 10+ hours because you fixed an issue you weren’t asked to fix. Client is liable to be angry, other people in your firm would likely become involved, time spent in emails/calls to mollify anger.

If this was developed by another firm, let your client take them to task for their abject failure.

You have a responsibility to write decent code, and write appropriate test(s) (with assertions) to give you the ability to say that it works the way you expect, it’ll be able to be deployed, and it won’t cause other deployments to fail by causing the overall coverage to drop below 75%.

On why proper testing is important

I think my C-Suite elevator pitch would be the following three points.

  1. Software spends the vast majority of its life in maintenance (unless it’s bad software that gets tossed out immediately)
  2. The sooner you find an error, the cheaper it is to fix
  3. Tests help you find errors sooner

Unit tests (when done properly) give you (the developer) a level of assurance that the code is correct and behaves appropriately under a variety of circumstances, but unless you’re trying to convince another developer, it’s going to come down to how you can present it as a cost saver instead of a cost generator.

For that, I might say that proper tests (in general) can:

  • Let you know that the code produces the right results, giving you (the client) a measurable indicator for when a project is completed
  • Act as an early warning / also act as regression tests. If a code change (to your code, or in unrelated code) causes your code to break, you’ll know about it before that change has a chance to break things for real (which then incurrs cost to clean up/restore bad data, or import missing data that wasn’t captured due to the issue)
  • Is a predominately one-time cost. Sure, you (or others) may need to adjust tests or add tests over time, but I think that many tests end up being rather static. Contrast to ongoing costs if you have to find and solve the same problem multiple times
  • They’re automated! You don’t need to pay a bag of flesh and bones to run through a manual testing procedure over and over. Repetative tasks like this are what computers were born to do.

Attribution
Source : Link , Question Author : Scott Williams , Answer Author : Derek F

Leave a Comment