Continuous builds and Continuous Smoke Tests

Continuous builds and Continuous Smoke Tests - developers and testers perspective:

What is the purpose of continuous builds ?

1. To check if the source files are compiling properly as they are checked in by the team of developers. This does not seem to add value to the development methodology.
2. Is it to check if the unit tests are executing successfully ? Well certainly unit tests add a lot of value during development to test a successful integration. But consider during the initial stages of development (I will not talk about Iterations or Sprints), where developers are working on requirements and checking-in sources to the repository. This way the developers are adding functionality piece-by-piece in iterations and one is not able to complete the functionality end to end. Unit testing and coding are a developer's responsibilty.

But having continous builds and tests as part of the builds isin't going to add MUCH value to the overall development methodology. Yes, it is certainly going to help the developers a lot with their code integration. We (stakeholders) keep asking to involve testers right throughout the development phases. How can this happen ?

In Agile and RUP, functionality gets added in iterations and phases or in Sprints.
Does it mean we ignore the testing of the Project or Product until some of the initial functionality has been developed and marked done by the developer ?
Well, I am talking of the initial stages...Take for e.g (a trivial one) a login screen has been developed by developer D1 and where one has to enter a user ID, but no password is required to login into the application or product. The reason, is that the developer D1 or Developer D2 will work on the Password stuff later on in the coming iterations.

So what ?

Well, I do see we already started our continuous builds ( maybe three to four builds a day) and I see that the Application or the product has some working functionality as per the requirements and some shape is taking place with some other bits of functionality (NOTE: as per the requirements, well you do not throw away what you have developed so far).

So what is new ?

My thoughts are dragging towards the 'Smoke test(s)' that should be in place. I would recommend one smoke test a day very early in the project/product development.
Smoke tests are by definition are correct but interpreted with a narrow mind by managers and testers. Smoke tests must be manual ( DO NOT Automate Smoke tests in first release or milestone).

Why ?

This is where tester(s) get a chance to understand and see visually what is being developed from on paper. Is that all ?

No, testers get a chance to:

1. Understand the requirements and coordinate with the developers. Improved and better communcation.

2. Will be able to provide feedback on the developed functionality. This is a significant point where the testers get a chance to check back with the requirements if 'we are doing the right thing'. Discuss and refine the developed functionality sitting across the table with the developers.

3. Once we are done with smoke tests , testers will benefit from the interaction while functional testing. This sort of interaction would provide the testers better insight into the functionality and the requirements.

4. Testers get a chance to provide a feedback on 'future enhancements' , specially useful in case of product development.

Overall this improves and adds vaue to the development methodology.

Later and after the first milestone or even after the first major release, we can automate the smoke tests for the current release and execute these in the coming milestones, releases or phases.

Weblogic etc..

Pre Compile Java Server Pages (JSP) using ANT :

---

<java classname="weblogic.jspc" fork="true" failonerror="true" dir="${war.home}">
          <jvmarg value="-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"/>
          <jvmarg value="-Dweblogic.jsp.windows.caseSensitive=true"/>
          <classpath>
            <pathelement path="${weblogic-related.jars}"/>
            <pathelement path="${application-related.jars}"/>
            <pathelement path="${java.class.path}"/>
          </classpath>
          <arg line="-depend -compileAll -keepgenerated -d WEB-INF/classes ."/>
</java>

---

Weblogic.9.2 and JDK 1.5.0_011.
Weblogic 9.2 comes with JDK 1.5.0.04 version. If you need to point to JDK version 1.5.0_011, then you need to use a parameter:
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0

Make sure the domain is using the right JDK version. Make use of this parameter in startWeblogic.cmd/.sh files. Also can be used when running Ant tasks.

---

Java Utils

Some of my past works include the use of various JDK API:

---

Adler32 API Usage:
What is this API used for ?
Checksum is the answer. To compute the Adler-32 checksum of a data stream.
We need this in order to know if a data stream has changed in time.
Set the checksum and then read the file again to see if the checksum has changed. if so , meaning file has changed.
Check the code here.

 String fileContents = null;
 long adlerCheckSumValue = 0l;
 // read the file contents into fileContents as a string.
 Adler32 adlerCheckSum = new Adler32();
 checkSum.update(fileContents.getBytes());
 adlerCheckSumValue = adlerCheckSum .getValue();

 OR

 //get the check sum value from the given input stream.
  
 CheckedInputStream cis = new CheckedInputStream(inputStream, adlerCheckSum );
while (cis.read() != -1) {
         //Do nothing here
      }

      adlerCheckSumValue  =  adlerCheckSum .getValue();

---

Simple log4j logging configuration for simple utilities:
The Pattern logs this way :

[ INFO ]:: 2007-06-26 17:42:42,001:: com.xxx.xxx.xx.XXXXX.main(XXXXX.java:147):: This is the log message...

String pattern =  "[ %p ]";
        pattern += ":: %d";        
        pattern += ":: %l";
        pattern += ":: %m %n"; 
 
        PatternLayout layout = new PatternLayout(pattern);
        FileAppender appender = new FileAppender(layout, filePath);
        Logger logger = Logger.getLogger(theClass);
        logger.addAppender(appender); 

filepath is the absolute path with log file name.
theClass is the class object.

---