Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are doing software testing by testing a lot of I/O cases, so developers and system analysts can open reviews and test for their committed code within a given time period (e.g. 1 week). But when it come across with extracting information from a database, how to consider the cases and the corresponding methodology to start with?

Although that is more likely to be a case studies because the unit-testing depends on the project we have involved which is too specific and particular most of the time. What is the general overview of the steps and precautions for unit-testing?

share|improve this question

closed as not constructive by Jim G., gnat, Walter, StuperUser, Dynamic Oct 15 '12 at 19:12

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

What is the general overview of the steps and precautions for unit-testing?

Unit testing is validation and verification methodology where the developers test the individual units of source code. General steps consist from triple A methodology. Meaning having steps of "Arrange-Assert-Act”.

Main precaution with unit test is, your unit test should test a single unit of work per unit test. Once you have more than single purpose in the method, or unit of code that you are testing then purpose of unit-testing is broken at that point.

References to look: There is a very good MSDN article on - How to: Create a Data-Driven Unit Test and good practices to follow in - Write Maintainable Unit Tests That Will Save You Time And Tears.

share|improve this answer
As for creating the data-driven unit test, can we create a dummy database ? It seems that in the example, the developer is trying to create a local database for testing. – Raju Gujarati Oct 12 '12 at 16:14

It's not useful to talk about unit testing in a vacuum.

The usefulness of a unit test is dependent upon how well it tests an acceptance criterion a granular unit of functionality which fulfills an acceptance criterion. Also, that unit test must be readable and it must be easy to maintain because acceptance criteria are always subject to change.

share|improve this answer
Acceptance criteria exist on a much higher level than unit tests, so usually they can't directly be tested this way. Unit tests test a small part of the code in isolation, while acceptance criteria refer to the whole system. – Péter Török Oct 12 '12 at 7:26
Actually, it's not useful to talk about anything in a vacuum. No air, so it's impossible to hear anyone. – SomeKittens Oct 12 '12 at 14:11
@PéterTörök: You are correct. Please see my edit. – Jim G. Oct 12 '12 at 14:54
Is it trying to satisfy the criteria for each componenet and then the whole system if we run a System Integration test ? – Raju Gujarati Oct 12 '12 at 16:10
@LoWaiLun: Yes. – Jim G. Oct 12 '12 at 16:12

Setting up the database for testing is a pre-condition for your test, albeit potentially more complicated than initializing some strings in memory. Deleting your setup information could be a post-condition (or not). You need a working database to test against, but there are many ways to accomplish that.

I agree with ElYusubov that it's easier to do good testing when you don't need any setup or teardown code and can run tests in any order, but some things require setup, and running a suite of tests after performing a complicated setup seems very reasonable to me.

In JUnit you would use something like:

public void setUp() {
    this.println("@Before setUp");
    this.myManagedResource = new ManagedResource();

public void test1() {
    this.println("@Test test1()");

public void tearDown() throws IOException {
    this.println("@After setUp");
    this.myManagedResource = null;
share|improve this answer

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