-4

The main logic of my function is a switch case, with the default case being the abnormal case.

function main(input) {
   let result = process(input)
   switch (result): {
     //normal cases
     case A:
        processA();
        break;
     case B:
        processB();
        break;
     ...
     default:
     handle_abnormal()
   }
   //further process input
   process2(input) 

}

As the above pseudo codes show the main login of my function are 3 steps: 1. process input 2. switch case the processed result 3. further processing the result.

To test main(), at some point the switch case block added a test case. The test logic is to send the input with some test data, then switch case handle that test case.

function main(input) {
   let result = process(input)
   switch (result): {
     //This is a test case
     case T:
        processT();
        break;
     //normal cases
     case A:
        processA();
        break;
     case B:
        processB();
        break;
     default:
        handle_abnormal()
   }
   //further process input
   process2(input)  
}

There were two reasons to add that back then, 1. it is easier to generate the test data (than the normal cases) 2 with that test case we can easily verify the whole processing of main() run as expected.

But now that test codes exist in the production codes! Although I have to say because of that test codes I am indeed feel more confident when refactor the main() function.

I have been trying to remove the test case from the production code, but to no avail.

  1. typescript does not support preprocessor, e.g. https://stackoverflow.com/questions/32906097/preprocessor-defines-in-typescript so I don't have a preprocessor to remove it.

  2. Although terser has "conditional-compilation" to remove dead codes, but I find it won't work in my case. Through my test, terse's conditional-compilation is quite limited.

  3. I have tried to write some standalone test code to test my main function so I can move that test case in to the test code. But because it is inside that switch case block I can't find an easy way to move it out (at some point I just feel it does not worth the effort)

How do I remove those test codes out ? Or it is just not worth the effort ?

--- update ---

Based on the comment

The code is to monitor/analyze data traffic. To test it the normal process is to start a package data sender from other machine. So to simplify that we just start the package data sender from localhost and the T case is to handle the data from localhost. All the other processing remains the same.

5
  • 1
    I think your question is missing some crucial details. It is quite unclear why you need this extra case T. Usually, I would expect any test simply call the original "main" with different inputs, where the inputs trigger execution of the branches A, B, ..., and "default" in the switch statement. There is surely a reason why you implemented this differently, but currently this reason stays hidden.
    – Doc Brown
    Commented May 27 at 5:57
  • As I said in the question, "it is easier to generate the test data (than the normal cases)" Commented May 27 at 7:56
  • The code is to monitor/analyze data traffic. To test it the normal process is to start a package data sender from other machine. So to simplify that we just start the package data sender from localhost and the T case is to handle the data from localhost. Commented May 27 at 8:06
  • 1
    Your explanation is definitely too terse to be understandable (at least, for me). To give you an example, if "input" is some data package to be analysed, why does it matter from which machine it is coming. But before you try to give me another terse explanation here in the comments (which probably wouldn't help), try to rework your question from the beginning, add more context and semantics into the example, describe your use case in terms with meaning, not just "input", "process", "processA". Assume we don not know anything about your system.
    – Doc Brown
    Commented May 27 at 10:09
  • ... and I will be happy to remove my close-vote after the clarity of the question was enhanced.
    – Doc Brown
    Commented May 27 at 19:18

1 Answer 1

0

It looks like the main() method is doing multiple things. This breaks the single responsibility Principle.

If you move the switch into a separate method (switchMethod in my example), like you did with process() and process2() you would be able to easily send test data into that method.

If that switchMethod needs external data for testing you can mock that data of just push it straight into the method.

The main method would then only be the controller (it looks also like a controller as in MVC). It will direct the data flow between the methods. The real decisions and processing are in separate methods.

If that does not fully answer we need a bit more info as you don't send data into the processT/A/B methods.

2
  • I had thought about using switchMethod like you mentioned. But the problem is inside switchMethod how do I know this is the mock data, so it will be handled differently. The codes that handle the test data differently remains in the production code and that is my problem. Commented May 28 at 2:12
  • In general: the code should not be different for testing. Is should be the same. The input data is what can be real or a mock. So you wrote that you are processing packages: send fake packages (mock) to the methods and process that. Your methods should not be aware what is real and what is not. Commented May 28 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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