1

I know that McCabe basis path testing ensures that all linearly independent paths are tested, making sure that all code branches were covered in an effective manner. But nowadays, I doubt anybody designs tests from the source so I am thinking whether this can be used on a higher level, e.g. general flow of an application? If I apply the same rules for counting CC and then design the tests to cover "branches", for example states in the state chart diagram, making sure all transitions were excercices (but well, there is state transition testing for that I would say?)

Does it make sense?

  • Yes,it makes sense but might not be worthwhile – Basile Starynkevitch Jul 4 '17 at 16:53
  • But nowadays, I doubt anybody designs tests from the source -- Why? – Robert Harvey Jul 4 '17 at 17:59
2

Static code analysis can identify all linearly-independent paths and discover edge cases. Once these are identified, unit tests can be crafted from that analysis to exercise all of the independent paths and edge cases. This is essentially white box testing. Unit tests can be written manually, or they can be code-generated.

It's highly likely that such analysis takes place, not at the source-code level, but probably at the level of the AST (abstract syntax tree) in the compiler, or at the byte-code/intermediate language level (where adequate metadata exists to support the analysis).

When I hear the phrase "whether this can be used on a higher level, e.g. general flow of an application," I think of integration tests, not unit tests. How your application's components integrate is largely a matter of the software architecture that you choose. In a good architecture, these tests are, shall we say, "uninteresting," in the sense that they don't really test actual functionality, but merely confirm that you've connected your working components together properly.

Above this level you enter the domain of acceptance tests. Acceptance tests are generally devised against functional requirements, and wouldn't benefit much from path analysis, in my opinion. Your difficulties there arise from the inherent brittleness of automating such tests. Again, a good architecture would lean more heavily on verification via unit tests.

Example
Generate unit tests for your code with IntelliTest

IntelliTest explores your code to generate test data and a suite of unit tests. For every statement in the code, a test input is generated that will execute that statement. A case analysis is performed for every conditional branch in the code. For example, if statements, assertions, and all operations that can throw exceptions are analyzed. This analysis is used to generate test data for a parameterized unit test for each of your methods, creating unit tests with high code coverage.

In short, sure, you could do all of this by hand, but a machine can do it better, faster, more thoroughly and with fewer errors.

  • My question was a bit different. Imagine you have a flowchart, describing a flow in an application like this: Screen A---> Screen B <> decision -- Screen C .... I would say I still could use CC to count number of paths I should execute.Similarly to state transition tests. – John V Jul 7 '17 at 5:36
  • What about it? Don't you have acceptance tests? – Robert Harvey Jul 7 '17 at 18:01

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.