• people
• teams
• projects
• requirements
• architecture
• modeling
• testing
• documentation
• process
• knowledge
• outsourcing
• tools

From the above, I believe that teamwork and testing are becoming increasingly relevant and valuable in our professional.
I must agree with him that these topics were either not taught at all or they were not taught very effectively due to the lack of focus given to these “non-technical” topics (with the exception of architecture – which usually didn’t get ). At least that was how it was when I was at university (I graduated in 1996 at U.C. Berkeley). Perhaps there is more focus on them these days. At that time, they were starting to realize that being able to work in a group is important for the students into workplace. So they started putting people in groups to do assignments. I believe in teamwork because it is better for the company as a whole. A team that can work together and share knowledge amongst members is more valuable to the company than an individual who is supposedly `really good´. If this individual does not share his/her knowledge, then the company gets only limited benefits of the individual’s potential. In a story that I heard from Jeff Sutherland – one of the creators of Scrum – the combined effort of a team out-performed the effort of a ‘really good’ individual – an individual considered 5 times as good as the other team members. This performance was measured when the Scrum master kicked the ‘really good’ individual out of the team. Turned out that he was disrupting the performance of the other team members by refusing to work together with them.

Another topic is increasingly relevant these days for a developer is testing. Again, testing is hardly ever taught in school. I’m glad to see as over the years testing has become more and more prominent. Any developer that does not know or does not care about testing is definitely old-school and out-dated. A good developer cares about about writing testable code and has is equipped with a list of testing tools in his skillset.

Here are some of the great quotes from the talk:
A fool with a tool is still a fool but a dangerous fool
Tools are not enough, but proper use of the tools is what is important. Companies often decide on new tools without investing in training for these tools.

Software is developed by people not by process and tools
I have been always saying about agile is that it puts the human element back into software development. That is the really that it has an effect on motivating people. Feedback motivates people. Doing a good job motivates people.

Software development is like a football game – lose together or win together
When you play football, you don’t say, “I did great – I scored 3 goals – but the goalie, he let in 5 goals – he’s terrible.” Either you win as a team or lose as a team. Winning or losing may come down to your ability to work as a team.

Think big, build incrementally
This reminds me of the discussion about whether people prefer to use user stories or use cases in agile. A good explanation of the difference highlights the reservation that people have about user stories as being too narrowly focused. With requirements as with architecture, it is important not only to keep the big picture in mind, but to find a good balance between the big picture and the details. Some companies have a good grip on the big picture, while losing sight of the details, while some other companies focus on the detail without a big picture, resulting with an inflexible system.

Architecture without executable code is a hallucination
This is something that I feel strongly about. I call myself a hands-on architect – perhaps I should call it non-ivory-tower architect. The real world is not perfect like it seems from the ivory tower. Architecture is only valuable when it has been proven. Ivar says: Start by building a skinny system to demonstrate that all critical risks have been eliminated.

Law of Nature: People don’t read documentation
Only write the essentials and leave room for conversations and self-discovery later. In school, we are taught to think for ourselves, but often in the workplace, especially a big company, we are asked on our first day to read endless documentation. Honestly, I do a skim through of the table of contents and maybe the first pages. It is a pain to read through a big document. Write down the essentials with attention to bringing across the main ideas in a few words as possible.

The smart way to do testing: We are all testers!
Clean up after ourselves. Testers are the real thinkers.

I really agree with what Ivar ended the talk with:

We cannot all be equally smart, but we can all become smarter.

You got a team of people, so why not make sure everyone is working at their best potential.

Selenium comes in several version: IDE, core, remote-control, grid.

First, Selenium IDE is used to create tests and run them during test development. It comes as a Firefox plugin, which means that installation happens in one click. One of the biggest advantages of Selenium is that the tests are stored in HTML, which is easy to understand and easy to manage even without a lot of technical knowledge, making it perfect for functional testers. In addition to creating tests by recording user interactions, tests can also be manually built up from a large list of commands, implemented in Javascript. Some of these commands use XPath or DOM for specifying elements within a web page.

If the HTML/Javascript solution is not enough to expression your test scenarios, tests can be written in Java, C#, Perl, PHP, Python, or Ruby. Selenium IDE even converts an HTML script to any of the above languages for you as a starting point. But once code that cannot be converted back to HTML are introduced in the test, the test can no longer be run within the IDE, but must be compiled (if necessary) and run with Selenium RC (see below).

Second, Selenium RC (remote-control) is used for running the tests from the command line and remote from the application server, making it easy to integrate into a nightly build. Since Selenium is Java-based, it can be run in any OS that supports Java. Selenium RC encapsulates Selenium Core, which was the initial product that requires tests to be deployed together with a web app. This means that Selenium core is probably no longer used by itself.

Lastly, Selenium Grid encapsulates several Selenium RC servers and allows the tests to be run in parallel on multiple machines. This is useful to start the tests on several different OS at the same time, driven from one process.

Selenium seems to be perfect for functional testing. It is easy to adopt, but is flexible enough for more complicated test scenarios which can be written in a variety of languages.

Selenium references:

• Selenium IDE documentation
• Selenium command reference
• Selenium forum

As part of a huge refactoring effort, I’m working with the TestNG, Maven, Netbeans. Not surprisingly, everything has not been a breeze. So I put together these steps to set up test development using TestNG and Maven, and debugging with any IDE. In fact, TestNG can be easily replaced by JUnit here. It’s more about getting around the Maven build life cycle during test development.

1) Skipping the Maven test phase until test development is complete

The first problem I encountered was that the jars get created at the install phase near the end of the Maven build life cycle, which means that if the tests fail, the jar never gets created. Apparently, this is not meant for test development. The solution is to turn off the test phase by setting skip to true in the configuration of the surefire plugin, until all tests pass and can be used for automated testing.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
<suiteXmlFiles>
<suiteXmlFile>src/test/config/testng.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>

2) Copying all dependencies to target/lib

This is usually done for any jar that is an executable (contains a main method), so that you can reference the dependencies easily from within the jar manifest.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>dependency-maven-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>

3) Referencing dependencies in the jar manifest

The following creates a manifest in the jar with references to all the dependencies previously copied to lib. Note that the classPrefix is lib.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<jarName>myapp</jarName>
<archive>
<manifest>
<mainClass>com.mycompany.MyApp</mainClass>
<addClasspath>true</addClasspath>
<classpathPrefix>lib</classpathPrefix>
</manifest>
</archive>
</configuration>
</plugin>

4) Packaging the tests

Next, I add a Maven goal to produce a jar of the test sources.

mvn clean install jar:test-jar

This produces a jar (myapp-tests.jar) in your target directory next to your normal jar (myapp.jar)

5) Running the tests with TestNG

Then, I run the tests on the command line using TestNG instead of via Maven.

java -cp ./target/myapp.jar;./target/myapp-tests.jar; org.testng.TestNG ./src/test/config/testng.xml

I put the testng.xml in the config directory instead of resources because it is a runtime configuration and does not need to be part of the jar. Everything in the resources directory gets added to the jar.

6) Debugging the tests
Debugging the tests is simple.

java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,address=8888 -cp ./target/myapp.jar;./target/myapp-tests.jar; org.testng.TestNG ./src/test/config/testng.xml

From your IDE, attach your debugger to port 8888 using a SocketAttach to attach to an external program.

Current method:

String currentMethod() {
return Thread.currentThread().getStackTrace()[3].getMethodName();
}

The number in the stack trace changes depending on how far down you bury this call.
Really handy for unit testing or debug logging (remember to wrap debug logging with logger.isDebug()).

While most of us know JUnit, TestNG is a similar test framework that was designed to test at a slightly higher level than JUnit. On the surface TestNG and JUnit are very similar, especially since JUnit 4 makes use of annotations. In addition to flexible method naming, TestNG provides features that I often missed in JUnit – namely, test order and dependency.

First of all, TestNG has the concept of a test suite that is more useful than just a dumb grouping in JUnit. You can specify order and have dependency testing – skipping, instead of running tests that depend on others that failed. This reminds me of having to name the tests in alphabetical order in JUnit just to impose an order. Dependency testing helps enormously with continuous integration by allowing the test run to finish and report earlier when something goes wrong. The idea is to have an early warning system.

Secondly, TestNG provides parametric testing, which means you can run the same test code with different parameters allowing more thorough testing of an area of code. In TestNG, parameters are specified in the annotations. Parametric testing is reminiscent of the FitNesse framework, where parameters are specify in HTML tables. However, as a developer, I prefer to work with XML (testng.xml) than HTML. Also, I find it extremely unlikely that someone (even if non-technical) would feel more comfortable with HTML than XML.

In the end, no matter what test framework you use, it is just a tool. You still have to come up with the right testing strategy. For me, TestNG is a very useful option, especially for higher level comprehensive test coverage.

Reference:

• In pursuit of code quality: JUnit 4 vs. TestNG