SVN Modified File Checkins - Guidelines

In any software project development, we use configuration tools such as SVN, ClearCase etc for configuration management activities. We work on the project files and check in them back to configuration server after we are done working on those files. In a bigger projects, there will be thousands of source files that project members will be working on. The activities involved are checking out the source code, work on them and then check-in the modified project source files. Checking in huge number of modified files(Jar, EXE, DLL etc) is sometimes not an easy task if proper guidelines are not followed. Every check in has effect on the existing source base and often developers fail to realize the effect or realize it too late. In this short article, I am going to explain few guidelines while checking in the modified source files keeping SVN(Subversion) as example.

•  Take an SVN update on all the source files that are potentially impacted by your local modifications.

• While taking SVN upate, there are chances of merges being happened. The merges will sometimes be merged well with your changes or there can be conflicts. Resolve the conflicts manually and verify that your changes are appearing. Its best practice to keep a backup of all your modified files since conflicts can be confusing and you tend to revert your changes and freshly want to merge your changes using some tools called beyond compare etc.

• Build all the project modules to verify that there are no compilation errors. 

• If any error occurs (this could usually happen because SVN didn't merge correctly or some dependency between classes broke) then fix those errors and compile again

• Once there are no compile errors commit your changes

The bove steps can also be automated by using SVN commands. The most used SVN command lines are as follows

• svn update [Path to project files]
• svn commit [Path of the file(s) to commit> --message <commit comment]
• svn resolve --accept=ARG [PATH...]
• svn resolve [Path of file(s) to revert]
• svn checkout checkout URL[@REV]... [PATH]
• svn add [Path of files to add]  - Adds non version-ed files to subversion
• svn log [Path of the file location or revision] - Shows the log messages for a set of revision(s) and/or file(s) 
• svn status [Path] - This can be used to print the status of local files or files in the repository.

Furthermore you can also integrate your batch file or ant script with your IDE. In eclipse,

• Go to Run->External Tools->External Tools Configurations.
• Create a new Ant build for ant scripts or Program for your batch file
• Point to your ant script or batch file. Click Apply and then click Run.
• The external tool will now appear in the Run->External Tools->External Tools Configurations menu.

 For a complete guidelines on Configuration Management, visit Configuration Management Best Practices.

Types Of Software Testing

"My Software never had bugs; it just develops random features!" - This is a famous software developer quote. A better way to say there are bugs crept in the software. Let's answer the question 'when software is said to have bugs?' Well, when software behaves in an unexpected manner. In other words when your software produces a behavior that is never ever defined for it. This can happen due to several reasons. Have a look at different types of software errors and how to deal with them. In this article I'm going to explain what are the typical types of software testing methods to detect unexpected software behavior.

Unit Testing(UT)

Well, this is the most powerful and essential testing method. Unit testing is carried out by the developer himself/herself to see if the code written by him/her works as expected. In this type of testing, every method/ function written is tested for boundary conditions and for each conditional statements used in the method. Unit test cases are written prior to unit testing the code. There are two types how unit testing is carried out.(1) Automated Unit Testing - This is done by writing the code to test the code. There are tools/frameworks to do this. For Java code, the tool is called JUnit. (2) Manual Unit Testing - The possible unit test cases are written in a document in English Statements and then executed one by one. Manual unit testing is a time consuming method. The best practice is to use code coverage methods during Unit Testing to see if sufficient test cases are written. See how to collect code coverage reports for Java Code.

Developer Integration Testing(DIT)

In this type of testing all the public interfaces are tested to see they integrate well with all the modules in the project. As the name indicates, this type of test is executed by developers. DIT is very important method of software testing since DIT decides if all the software modules 'integrate' well themselves. DIT is a nightmare if public interfaces are not well defined. The best practice is that public interfaces are to be developed by a person who understands entire software architecture usually by a System Architect.

System Integration Testing(SIT)

System Testing is carried out by testing team and usually not by developers. Testing team develops system test plan and executes them. System testing also comprises  of Capacity and load testing of the software as a whole system apart from testing how well the software system under testing integrates with rest of the systems in the software portfolio. This especially important where a software product needs to work with different software products in an enterprise solution.

Smoke Testing(ST)

This type of testing is also known as acceptance testing. This test is carried out to see if there is any 'smoke' in the software before even full fledged software testing is taken up by the testing team. If the software has smoke, then further testing will be stopped and software build/release will be rejected until the smoke has been removed from the software by the developers.

Regression Testing (RT)

This type of testing is carried out by the system testers. Regression testing does not follow a definite pattern. The regression test cases are developed based on the code changes done. This type of testing very common in maintenance projects where the software is already developed and there some change requests (CRs) done on top of it and is given for testing it. See what should be the quality of regression testing.

The testing methodologies differ based on the type of the software being developed. For example, if its a software product then regression testing applies and usually not for software services. Not all software testing methodologies are mandatory for software testing. Software testing has been a challenge in the software development life cycle. People have hard time dealing with non reproducible software bugs. Have a look at my article on how to deal with non reproducible software bugs/issues.

Hope you enjoyed this article.