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?
0
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.
1
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.
5
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:
@Before
public void setUp() {
this.println("@Before setUp");
this.myManagedResource = new ManagedResource();
}
@Test
public void test1() {
this.println("@Test test1()");
}
@After
public void tearDown() throws IOException {
this.println("@After setUp");
this.myManagedResource.close();
this.myManagedResource = null;
}