Unit Testing: Beginner Questions

Question

I\'m finally starting out with unit testing, having known that I should be doing it for a while, but I have a few questions:

• Should or shouldn\'t I retest parent c

Answer 1

• Test parent, test child; if the child doesn't override the parent method, no need to retest it.
• I'm not sure I understand the second one. You can use Selenium to automate testing a form. Is that what you mean?
• Tests should include the "happy path" and all edge cases. If you have an optional parameter, write tests to show proper operation with the value present and absent.
• Unit tests, integration tests, acceptance tests, load tests are all different ideas that may have some overlap.
• I'll bet there are valid reasons, but if you're doing automated builds that run the test suite automatically why would you not run them? Maybe long run times come to mind, but that's the only reason I can think of. The value is seeing that all of them continue to pass, and that changes you've made haven't broken anything.
• Unit test to me means the class you're testing, which can have several methods. I associate them with classes, not forms. Forms mean UI and integration testing to me.

Answer 2

(Not quite in the same order as your questions)

• If the full test suite doesn't take too long, you should always run it complete. You often don't know which side-effects may result from changes exactly.

• If you can combine speed tests with your favorite unit testing tool, you should do it. This gives you additional information about the quality of your changes. But only do this for time-critical parts of your code.

• From Wikipedia: "A unit is the smallest testable part of an application."

Answer 3

Answers to questions in order:

• If parent classes are already tested then avoid duplication and just test the new aspects of the child or any aspects that the child changed.
• Not sure - have done very little PHP.
• Yes => test all aspects of the method.
• You could have some unit tests that test performance but they would be focused on performance where as others may be focused on testing functionality. Don't mix both in the same test.
• Ideally you should run them every time and often. Sometimes if the execution time is huge you might want to consider refactoring them into smaller suites and then only executing the effected suites when something changes - but still do everything periodically.

Answer 4

I'll answer the ones that I can.

Should or shouldn't I retest parent classes when testing the children if no methods have been overwritten?

You should fully test the parent, then test only what changes in the child.

If you have optional parameter in a method, should you write a test for both when they are present and when they are not?

Yes, test anything that causes a change in behavior.

Should unit testing in any way be combined with testing code execution time or should they remain completely separate?

They should remain separate. Unit testing is to test that a method does what it's supposed to. You should test code execution time at a system level, then break it down to find bottlenecks. Testing the performance of each individual unit will only lead to premature optimization.

Is there any valid reason not to run your full test suite every time?

If your test suite is huge and takes a long time, you might want to only run a subset of it while you're still developing. You should run the entire suite when you (think you) are done to make sure you didn't break anything else.

Just so I'm getting my terminology right, to what does the unit in unit testing refer? The class being tested? The method? The parameter? Something else?

"Unit" refers to the method being tested. This is the smallest unit that it makes sense to break software down to. A method for class A might use class B, but any test you write for that method shouldn't care. Just test that method.