0

We have been assigned an open source software to test! The software has 3 packages and each package has 10 or more classes and each class might have dozens of methods.

My question is that before I start structural (white-box) testing, do i need to understand every line of code in the software?

Do I need to understand the whole flow of program starting from main() method?

What is the approach I should take?

Anuj Kalra
  • 73
  • 1
  • 8
  • if it's white-box testing, then i'd say "no" you don't technically need to understand each line.. you just need to understand, at a fundamental level, what each functional piece accomplishes. – ddavison Dec 01 '15 at 21:37
  • You don't need to understand every line of code, but you do need to understand exactly what it should do. Then compare that with what it actually does do. – NickJ Dec 01 '15 at 21:38
  • if you have specs on what each method needs to do - what is expected out for specified input then no you don't need to go into implementation details of those methods. You could write unit tests that check if methods are satisfying predefined contracts (if there were such) – Milan Dec 01 '15 at 21:42
  • like what each method is supposed to do? and then find out what sort of values it requires and what output the method should give? – Anuj Kalra Dec 01 '15 at 21:43

3 Answers3

2

If you have specs on what each method is supposed to do: What is expected output for specified input then no you don't need to go into implementation details of those methods. Normally this should be written down!

You could write unit tests that check if methods are satisfying predefined contracts (if they exist).

If you don't have specs or with recent trend 'UserStories' you need to 'reverse engineer your specs' :) You would need to analyse each method to understand what is it doing, next you will check where those methods are being called in order to figure out what are the possible values passed in the method calls. Also from the calling methods you might get the idea what are the corner cases. And those you definitely want to test.

.... and slowly you learned the whole code :)

Milan
  • 1,903
  • 17
  • 16
0

No, you don't have to understand every line of code to write Unit tests. I'm not so experienced with unit tests yet, but what if seen so far is testing every (or most) methods that respond differently to a certain input (--> arguments, object variables ...).

So you have to know what a method does, when it successfully does things, and when it is suppose to fail. And for some methods even the turning points between those cases are important.

For Example

Let's say we have a method that sums two ints, that have to be equal to or larger than 0:

public static int sumInts(int a, int b) {
    if (a < 0 || b < 0) throw new IllegalArgumentException("'a' and 'b' should be 0 or above!");

    return a + b;
}

What you could test:

  • if a = 49 and b = 16, does it return 65?
  • if a = -3 and b = 4, does it throw an exception?
  • if a = 5 and b = -13, does it throw an exception?
  • if a = -46 and b = -13, does it throw an exception?
  • if a = 0 and b = 0, does it return 0?
  • if a = -1 and b = -1, does it throw an exception?

Of course, this is just a very simple example. What you test depends on your method. For this method, the last two tests would likely be totally unneeded. But there are methods that are more complex, where those could be useful.

regapictures
  • 371
  • 3
  • 12
  • Yeah we have tested similar programs during our lectures and tutorials. But seeing the level and size of the project that needs to be tested is quite overwhelming. I do not know the first thing about the correct inputs that needs to be given and what to expect as an output – Anuj Kalra Dec 01 '15 at 22:01
  • Yes, you have to know what the most important methods do in order to be able to write test for them. And 'auwch' when you didn't write them yourself... Good luck! – regapictures Dec 01 '15 at 22:11
  • 1
    but, you will learn so much by reading other people's code, trying to figure out what is the that they were thinking/doing, how different pieces of application interact and maybe if you are lucky you might learn some good design patterns – Milan Dec 01 '15 at 22:14
0

There are several types of tests.

  • Unit test tests the functionality of each method on different cases of input data. Like, if you have a BigInteger fact(int n) method, you have to write tests on normal positive integers, zero, negative integers and max/min values. There are several libraries which'll help you: JUnit,TestNG, etc.
  • Integration test tests the whole your application, all packages and classes as a group. See Arquillian project.
  • Also, you can write black-box tests using Selenium.
  • Much more types of testing like regression testing, load testing, etc. This is the work for QA engineer.

After dark ages of software industry the community finally came to some good unit testing practices:

  • Code coverage. We would be living in caves without code coverage metrics.
  • Fault injection helps you in building more robust and stable software.
  • Wide mocking usage to write more specific tests without dirty influence of the rest of your application.
Everv0id
  • 1,862
  • 3
  • 25
  • 47
  • just those 3 types? https://en.wikipedia.org/wiki/Software_testing#Testing_types :) – zapl Dec 01 '15 at 22:35
  • There was no need to list all testing types, OP did not asked about it. But thanks, i'll update my answer to remove incomprehension. – Everv0id Dec 02 '15 at 06:16