Here's what we saw:

A NullPointerException in the tearDown method (technically, in the @After method since we're using JUnit 4).  The error didn't give much clue as to what the cause was.

What happens in cases like this is that when the @After method causes an exception, that exception masks any previous exception that the @Before method or @Test method may have experienced.

To diagnose the problem, we comment out the contents of the @After method for the moment and then run the test again (maybe just running one test method (you can do this by opening the class in Eclipse's  Outline view, then right-clicking on one of the methods and Run As... JUnit Test) to avoid accumulating a bunch of gunk that the @After method would have cleaned up if it weren't commented out).  Now that we had removed the masking exception, the stack trace showed clearly what the problem was (in our case, there were some properties that needed to be set in a properties file).

Por este motivo se crearon las famosas aplicaciones de Pruebas unitarias. Que son muy eficientes y nos permiten comprobar el estado de cada uno de los modulos de nuestro sistema, algunas de estas aplicaciones son gratuitas y otras no.

Algunas versiones libres son:

NUnit (Para .Net)

JUnit (Para Java)

JSUnit (Para JavaScript)

ASUnit (Para ActionScript);

Dentro de cada una de estas paginas vienen ejemplos, Frameworks, documentacion, entre otras cosas, que nos ayudaran a facilitarnos el hacer las pruebas.

Cabe mencionar que Visual Studio en sus versiones TEAM, trae incluido una funcionalidad que nos permite realizar pruebas unitarias de una forma bastante simple y eficas.

Pruebe Visual Studio 2008 Team Suite (Por 90 dias)

Firebug was written by Joe Hewitt, who worked on Netscape back in the day and wrote large parts of the early versions of Firefox. Pretty much a demi-god when it comes to browser technology. I think he works for Facebook now.

Anyway, I was using Firebug today and I discovered a very useful feature: Copy XPath. Anybody who has written XPath strings by hand will know that it's a very tedious and error-prone business, so this feature is a god-send.

Just right-click on any HTML element and choose 'Copy XPath' from the menu to copy that element's XPath to the clipboard. Just bear in mind that the generated XPath string is lowercase. XPath is (generally) case-sensitive, so you may need to convert it to uppercase to make it work.

This feature comes in particularly handy for some work I'm doing at the moment, namely automatic testing of a web application using watij (Web Application Testing In Java, pronounced 'wattage'). This is a tool that allows you to automate IE from Java, telling it to open pages, click buttons, etc. It integrates nicely with JUnit, allowing you to unit-test your web application with ease. In an ideal world, your web-app's HTML would be liberally sprinkled with names and ids, allowing you to easily tell watij what you want IE to do and what results you expect, but if you don't have that luxury, then really XPath is your only choice.

Valtech is a highly regarded global business consulting and technology services company.

To help clients hit their constantly moving business targets, Valtech makes IT “business-friendly”. With thought leadership in Agile Methodology, Software Quality, IT Knowledge Transfer and Open Source solutions, Valtech provides a refreshing approach, capable of delivering sure-fire results and IT self sufficiency in any fast-paced business environment.

Valtech supplies management, technology and ebusiness consulting, global sourcing and learning services to forward-thinking companies. With over 1,100 employees, the company operates 17 offices located in the US, Europe and Asia. Founded in 1993, it is listed on the Paris stock exchange.

Job Description: J2EE System Designer

Years of Experience : 6+ Years

Location : Bangalore 

Offer #IND-02-06J2EESD

Skills : Educational Qualification: BE/MCA/Equivalent J2EE/Hands on Java Experience of "big" system architecture OOAD/UML Eclipse/plug-in devlopment JMS, Web Services Design Patterns JUnit

Professional experience : Websphere Commerce SWT MQ series XML RDBMS (DB2) Rich Client (RCP) Development Agile methodology

Responsibilities

• Ability to understand the architecture, contribute to architecture (assist architect) in coming out with a solution
• Significant experience in designing systems using Object Oriented Methodologies
• Help developers in resolving technical problems and to promote knowledge sharing
• Perform Technical Reviews (Design/Architecture/TestDesign,Code)
• Hands-on in Java coding
• Strong in OOAD
• Strong in Junit
• Supporting the developers – making sure that the developers are able to realise the architecture, by a combination of mentoring and direct involvement
• Ability to identify design patterns and implement it

This job is posted in http://www.valtech.co.in/ for more details visit http://www.valtech.co.in/in/index/careers/job/IND-02-06J2EESD.html

Nội dung
1.    Viết Unit Test để giảm các rủi ro
2.    Viết một Test Case cho mỗi component quan trọng
3.    Viết Abstract Test Case và Test Utilities
4.    Viết các test hiệu quả (smart tests)
5.    Thiết lập môi trường phù hợp cho mỗi test
6.    Sử dụng Mock Object để viết test hiệu quả hơn
7.    Refactor các test khi refactor code
8.    Viết test trước khi sửa lỗi
9.    Sử dụng Unit Test để bảo đảm hiệu suất (performance)
10.    Viết test cho concurrent code
11.    Thực thi các test một cách thường xuyên
12.    Lời kết
-------------------------------------------------------------------------------------------------------------------------------
Lời nói đầu
Unit Testing là một trong những phần trọng yếu của phương pháp phát triển phần mềm linh hoạt (Agile Software Development), được giới thiệu lần đầu tiên bởi Kent Beck. Unit Testing giúp lập trình viên giảm thiểu tối đa các lỗi (bug), giảm thời gian tìm kiếm lỗi (debug), tạo ra được những phần mềm có tính ổn định cao.
Hầu hết mọi người đều xem nhẹ Unit Test, nếu có viết thì cũng viết cho qua loa, lấy lệ vì mọi người bảo rằng viết Unit Test mất thời gian. Đây là một suy nghĩ không đúng. Theo kinh nghiệm của mình thì đây chính là một phần gây ra việc mất thời gian debug về sau mỗi khi xảy ra lỗi, thời gian này tiêu tốn gấp nhiều lần đối với việc viết unit test.

Trong bài viết này mình đưa ra 12 mẹo mà các lập trình viên có thể áp dụng, không quan tâm đến môi trường hay ngôn ngữ lập trình nào. Mỗi ngày mình sẽ viết 2 mẹo. Nếu các bạn có ý định phổ biến bài viết này ở nơi khác xin hãy giữ nguyên tác giả và hãy để liên kết đến bài viết này trên blog của mình.

Hôm nay mình viết 2 mẹo đầu tiên

1. Viết Unit Test để giảm các rủi ro Một lập trình viên nào đó có thể hỏi: Tại sao tôi nên viết các test case? Chứ không phải việc testing nhàm chán này có nhóm QA lo rồi sao? Với tinh thần này chúng ta sẽ không có chỗ đứng trong môi trường công nghệ phần mềm hiện đại ngày nay. Mục tiêu chính của một nhóm phát triển phần mềm là phải làm sao tạo ra được những sản phẩm phần mềm có chất lượng tốt nhất. Người dùng cuối (end-user) rất khó chấp nhận các phần mềm bị lỗi, thiếu ổn định. Hiện nay hầu hết các thư viện (lib), web service và IDE (Integrated Development Environment) đều hỗ trợ refactor và unit testing, vì thế sẽ không có lời xin lỗi nào cho những phần mềm, đoạn mã chương trình bị lỗi.
   Ý tưởng đằng sau Unit Testing là tạo ra tập hợp các test cho mỗi thành phần của phần mềm (software component). Unit Test tạo thuận tiện cho việc phần mềm được test liên tục; chi phí thực hiện các test này khá rẻ so với test thủ công (manual test)
   Mỗi test case được xem như là giấy bảo hiểm cho hệ thống phần mềm của bạn. Có một lỗi (bug) trong mã chương trình, điều đó có nghĩa là có một rủi ro tiềm ẩn trong hệ thống. Việc viết các unit test sẽ giúp cho lập trình viên giảm số lượng lỗi và các rủi ro với các đoạn mã chương trình.
2. Viết một Test Case cho mỗi component quan trọngKhi bắt đầu unit testing, hãy luôn đặt ra cho mình câu hỏi: Những test nào mình nên viết?
   Ban đầu nên đẩy mạnh việc viết các cụm test chức năng, nghĩa là kiểm tra thăm dò các chức năng của hệ thống. Điều này không đúng. Chỉ tạo ra một test case (một tập hợp các test) cho mỗi thành phần quan trọng (major component) của hệ thống phần mềm.
   Tại một thời điểm chỉ tập trung viết test cho một component . Trong phạm vi một component, hãy nhìn vào interface của component đó mà viết test. Các bạn nên viết ít nhất một test cho một phương thức public thuộc interface đề cập ở trên.

Hôm nay mình tạm dừng tại đây. Hẹn các bạn ở các mẹo tiếp theo.

Duy Đỗ

I was getting a NullPointerException when I started writing the unit test for my little TransactionManager wrapper class.  I am using Unitils to manage all the dependency injection, so my test class looks something like this:

[sourcecode language='java']

public class TransactionManagerTest {
    @Mock
    @InjectIntoByType
    private PlatformTransactionManager platformTransactionManager;

    @TestedObject
    private TransactionManager transactionManager;

    @Test
    public void testCommitException() {
        transactionManager.commit();
    }
[/sourcecode]

I first got the NullPointerException while trying to test TransactionManager's getTransaction() method, but it has some more complex logic, so I decided to back off from that and test the commit() method first.

I had expected that when I called transactionManager.commit(), I would get the unchecked exception that commit() throws when you haven't called getTransaction() first.  But instead, this NullPointerException.

Before looking at the answer, can you guess why that would be?

Oh, wait, I already gave it away at the top of this post. Rats!

(Maybe there's a reason I'm a programmer instead of a game show host. ;)

Yup, that's right, folks!  All it was, was, I needed to...

[sourcecode language='java']

@RunWith(UnitilsJUnit4TestClassRunner.class)
[/sourcecode]

See ya next time!

The spec I wrote currently looks like this:

class PublishSiteGraphSpecTest extends JUnit4(PublishSiteGraphSpec)
object PublishSiteGraphSpec extends Specification {
  "directories are nodes" in {
  }
}

Let us fill in the details about what we actually mean when we say that directories should be nodes:

class PublishSiteGraphSpecTest extends JUnit4(PublishSiteGraphSpec)
object PublishSiteGraphSpec extends Specification {
  "directories are nodes" in {
    val source = new MemoryResourceRepository()
    val target = new MemoryResourceRepository()
    val problems = new ProblemsStub()
    val graph = new PublishSiteGraph(source, new SiteJobQueue(),
                                     new ContentNodeFactory(source, target, problems))
    source.importResource("directory/resource.ext",
                          new StringResource("directory/resource.ext", "the contents"))
    graph.findNode("directory") must haveClass(classOf[DirectoryNode])
  }
}

And it fails with an exception saying:

The file "directory" does not exist

The problem is that MemoryResourceRepository does not add resources for the directories on the path. So we ignore this test for now and move our focus to the MemoryResourceRepository:

class PublishSiteGraphSpecTest extends JUnit4(PublishSiteGraphSpec)
object PublishSiteGraphSpec extends Specification {
  "directories are nodes" in {
    skip("Won't work until MemoryResourceRepository adds resources for directories.")
    val source = new MemoryResourceRepository()
    ...
  }
}

And now JUnit ignores the test and builder outputs this:

Running tests in publisher:scala-core
Running java com.agical.publisher.content.site.PublishSiteGraphSpec
Specification "PublishSiteGraphSpec"
  specifies
  o directories are nodes
    Won't work until MemoryResourceRepository adds resources for directories.
    (PublishSiteGraphSpec.scala:19)

Total for specification "PublishSiteGraphSpec":
Finished in 0 second, 54 ms
1 example (1 skipped), 0 assertion, 0 failure, 0 error

Ok, let's move on with the next spec:

class MemoryRepositorySpecTest extends JUnit4(MemoryRepositorySpec)
object MemoryRepositorySpec extends Specification {
  "directories are resources" in {
    val repository = new MemoryResourceRepository()
    repository.importResource("directory/name.ext",
                              new StringResource("directory/name.ext", "the content"))
    repository.getResource("directory") must haveClass(classOf[DirectoryResource])
  }
}

And a familiar failure is seen:

The file "directory" does not exist

Time to implement

Firstly break break the path into path-elements

override def defineResource(name:String):OutputStream = {
  val path = name.split("[\\/]")
  createDirectoryRecources(path.toList)
  ...
}

Secondly, define the method that creates the directories. All but the last elements are assumed to be directories. Therefore we use the dropRight(n:Integer) function before we iterate the path-elements. Note how we can pass the function createDirectoryResource(name:String) as an argument to foreach.

private def createDirectoryRecources(elements:List[String]) =  {
  elements.dropRight(1).foreach(createDirectoryNode)
}

Thirdly we implement the createDirectoryResource function. Here we use the getOrElseUpdate function on the mutable Map. The getOrElseUpdateMethod simply looks for an element in the map, if the element exists it is returned, if the element does not exist it is created by the function passed in the second argument and returned.

We don't really care about the value here, we just use the second argument as an event to create directories that do not exist.

private def createDirectoryRecource(name:String):Resource =  {
  resources.getOrElseUpdate(name, {new DirectoryResource(name)})
}

We run the specs again:

Specification "PublishSiteGraphSpec"
  specifies
  o directories are nodes
    Won't work until MemoryResourceRepository adds resources for directories. (PublishSiteGraphSpec.scala:19)

Total for specification "PublishSiteGraphSpec":
Finished in 0 second, 87 ms
1 example (1 skipped), 0 assertion, 0 failure, 0 error

Running java com.agical.publisher.resource.memory.MemoryRepositorySpec
Specification "MemoryRepositorySpec"
  specifies
  + directories are resources

Total for specification "MemoryRepositorySpec":
Finished in 0 second, 149 ms
1 example, 1 assertion, 0 failure, 0 error

While MemoryResourceRepository does not work as we want it to work yet we can at least make the PublishSiteGraphSpec treat directories as nodes. So we remove the skip-statement and get the following error

Specification "PublishSiteGraphSpec"
  specifies
  x directories are nodes
    'com.agical.publisher.content.core.CopyNode@1f934ad'
    doesn't have class 'com.agical.publisher.content.core.DirectoryNode'
    but 'com.agical.publisher.content.core.CopyNode' (PublishSiteGraphSpec.scala:24)

Now the graph finds the directory resource but does not create a DirectoryNode but a CopyNode.

We jo-jo up and down in the code skipping as necesary until the SiteGraph-test passes and, implicitly, no skips remain.

We never specify something that is not driven by a need that can be traced back to our outer spec. Therefore when the outer spec works, by definition, no more skips remain. This is called outside in and is one of signifying aspects of BDD.

Making the spec into a contract

Now I find myself in the position where my specs pass but my userguide does not. I have made all the changes for MemoryResourceRepository and would like to make the same changes work for the FileSystemRepository. I need some way to test the same contract on both implementations.

Luckily specs provides a way:

class ResourceRepositoryTest extends JUnit4(ResourceRepositorySpec)
object ResourceRepositorySpec extends Specification {
  implicit def javaIterableToScalaIterable[T](iterable:java.lang.Iterable[T]):Iterable[T] = {
    new Iterable[T] {
      override def elements = {
        val iterator = iterable.iterator();
        new Iterator[T] {
          override def next = iterator.next()
          override def hasNext = iterator.hasNext()
        }
      }
    }
  }

  val root = getClass().getResource("/");
  commonSpecs(new MemoryResourceRepository())
  commonSpecs(new FileResourceRepository(new File(new File(root.toURI), "test")))

  def commonSpecs(repository:ResourceRepository) = {
    val oneResourceInOneDirectory = beforeContext {
      repository.importResource("directory/name.ext", new StringResource("directory/name.ext", "the content"))
    }
	"A "+ repository.getClass().getSimpleName +" with one resource in one directory" ->-(oneResourceInOneDirectory) should {
      "create directory resources for directories" >> {
        repository.getResource("directory") must haveClass(classOf[DirectoryResource])
      }
      "create regular resources for resources" >> {
        val resource = repository.getResource("directory/name.ext")
        resource.getName mustNot haveClass(classOf[DirectoryResource])
      }
      "the directory resource must " >> {
        val directory = repository.getResource("directory") match { case directory:DirectoryResource => directory}
        "be named after the directory" >> {
          directory.getName must beEqual("directory")
        }
      }
    }
  }
}

I simply wrap my specs in a method-definition and I pass the repository of choice as a parameter to my definition. Not too bad. The downside is that I now have a dependency to two different implementations from my contract-spec. The logical dependency direction would be the opposite in my opinion.

I'm on my way to be productive with specs. I'm still struggling a bit with how I should structure my specs but I think it is...

Time to wrap up with some final thoughts on specs

Specs does not impress me in the same way as rspec did. While most things seem to be possible it fails to guide me correctly. The documentation is pretty much features piled on top of features and it's sometimes hard to figure out when I would use one feature over the other. Moreover, rspec just seems to do the most logical thing with a minimum of effort while specs allows me to do the most logical thing with some effort. Also specs naming seems a bit awkward

Compare rspec's:

describe Account, " when first created" do
  it "should have a balance of $0"
end

that gives the output:

Account when first created
- should have a balance of $0 (PENDING: Not Yet Implemented)

Pending:
Account when first created should have a balance of $0 (Not Yet Implemented)

Finished in 0.007737 seconds
1 example, 0 failures, 1 pending

With specs:

package com.agical.publisher.resource
import org.specs._

object AccountSpec extends Specification {
  "Account when first created" should {
    "have a balance of $0" in {
      skip("PENDING: not yet implemented")
    }
  }
}

That outputs:

Specification "AccountSpec"
  Account when first created should
  o have a balance of $0
    PENDING: not yet implemented (AccountSpec.scala:8)

Total for specification "AccountSpec":
Finished in 0 second, 64 ms
1 example (1 skipped), 0 assertion, 0 failure, 0 error

The major thing to note is that rspecs that don't have a body become pending by default. Specs that don't have a body just pass and you can optionally add a skip statement with a description to achieve the same thing. I have this feeling in general that where rspec is very thought through specs seems to have more of a spray and pray attitude towards features. Ok, that's a bit harsh, specs is not bad, it's just not much more than ok in my book.

It's quite possible that I missed some nuggets in specs due to my expectations formed by rspec and I will continue to use specs since I think it is good enough for my needs.

Pfewww, that turned out to be quite a beast of a post. I'll try to keep them shorter in the future...

Let us see an example,
The BlogSearchService has two public methods, first method filterBlogsByAuthor takes an author name and a list of blogs and returns all the blogs written by that particular order author.
The other business method searchBlogs will take a search paramter and the author, it will get all the blogs by the search parameter using a custom logic and do some other house keeping tasks like sorting them by published date and number of comments and then filter the methods by author.

package com.teja.blogs;

import java.util.Collections;import java.util.List;

/**** @author Teja*/public class BlogSearchService {

      public List<Blog> searchBlogs(String searchString, String author){

              //do some custom logic here on these blogs like sorting them by posted date.              return filterBlogsByAuthor(author, Collections.EMPTY_LIST);      }

      public List<Blog> filterBlogsByAuthor(String author, List<Blog> blogs){
             return Collections.EMPTY_LIST;
 }

}

When writing the test cases for the second method, I don't want to test the other public method filterByAuthor as
(i)it has already been tested by other test cases,
(ii)I want to keep my test cases more unit.

So in my test case where I am testing my searchBlogs, I am creating the mock service class which has mock methods only for filterBlogsByAuthor, but the actual mehtod(searchBlogs) which is about to be tested is not.
As usual you can do expectations on the mock class, replay and verify as if it is some other external resource being mocked.

To create a partial mock class of the service, the extra parameter you need to pass is the name of the method to be mocked and the parameter types it accepts (coz, it need to know which version of the method you want to mock if you have overloaded methods)

Here is our test class:

package com.teja.blogs;

import java.util.Collections;import java.util.List;import org.junit.Test;import org.easymock.classextension.EasyMock;

/**** @author Teja*/public class BlogSearchServiceTest {

        @Test        
public void testSearchBlogs() throws NoSuchMethodException {
 String author = "Teja";
BlogSearchService blogSearchService =
EasyMock.createMock(BlogSearchService.class,BlogSearchService.class.getMethod("filterBlogsByAuthor", 
new Class[]{String.class, List.class}));
EasyMock.expect(blogSearchService.filterBlogsByAuthor(author, Collections.EMPTY_LIST)).andReturn(Collections.EMPTY_LIST);                EasyMock.replay(blogSearchService);                blogSearchService.searchBlogs("easymock", author);                EasyMock.verify(blogSearchService);        }

}

What does Buildr support?

Since I'm building with Buildr I would need a really good reason to go with something that Buildr can't handle. Let's have a look at what our options are:

Buildr supports three Scala testing frameworks: ScalaTest, ScalaCheck and Specs. Scala testing is automatically enabled if you have any .scala source files under src/test/scala.

...

Ok, ScalaTest, ScalaCheck and Specs in any combination. Choices, choices... After looking around in the documentation from all three frameworks I found the following:

• Scala Check is a scala variant of QuickCheck for Haskell. Scala Check is supported by both ScalaTest and Specs
• ScalaTest seems to me to be a rather traditional xUnit-style testing-framework. There are a few unusual constructs such as the FunSuite that uses functions instead of test-prefixed method-names to identify tests but in general ScalaTest feels like familiar territory with a few exotic flowers around.
• Specs is similar to rspec for Ruby and claims to be a BDD framework.

Both specs and Scala Test have JUnit-support which allows me to run my tests from JUnit. While this may not seem like a big deal at first it does give tremendous value when working with mixed code like I do, I can run all my tests/specs using the same JUnit-tool, this limits task switching and frankly improves the likeliness that I will run my tests/specs as frequently as I should.

Scala Check seems interesting to me since I have been playing witht JUnit 4.4 theories. I'm glad it's available in both frameworks so that my choice is not limited by that aspect.

I think I will take specs for a spin since I am a fan of rspec and BDD, I'm also curious how an rspec inspired tool would look in scala, it's bound to do things that can't be done in java. So more for me to learn that way seems to be the verdict.

Ok,

Through UGDD I have come to the conclusion that I need to add some features to the SiteGraph. I need to represent directories as nodes in the graph.

Installing specs

If you're a Maven user, you need to add the following dependency to your pom file:

    <dependency>
      <groupId>org.specs</groupId>
      <artifactId>specs</artifactId>
      <version>1.3.0</version> <!-- specify the version here ->
    </dependency>

In buildrish this translates to

SPECS = group("specs", :under=>"org.specs" :version=>"1.3.1")

It turns out that we also have to add the scala tools repository to our buildfile. I did not find that information on the site, perhaps this is already done in maven or it's so obvious that everyone that worked more than 2 days with scala is aware of that. This is how you add the repository to you buildfile:

repositories.remote << "http://www.agical.com/maven2/"
                    << "http://www.ibiblio.org/maven2/"
                    << "http://repo1.maven.org/maven2/"
                    << "http://scala-tools.org/repo-releases"

In order to run compile and run with specs we also need to add the following two lines to our buildfile in our scala-project:

test.compile.with SPECS
test.with SPECS

Ok, we're all set... let's write the first spec. Buildr dictates that we should put our specs in src/test/scala and name them according to the <SpecName>Spec.scala pattern.

Said and done, behold the first specification:

package com.agical.publisher.content.site
import org.specs._

object PublishSiteGraphSpec extends Specification {
  "directories are nodes" in {}
}

And now run it with buildr:

Testing publisher:scala-core
Compiling publisher:scala-core:test into /home/jocke/dev/publisher/scala-core/target/test/classes
Running tests in publisher:scala-core
Running java com.agical.publisher.content.site.PublishSiteGraphSpec
Specification "PublishSiteGraphSpec"
  specifies
  + directories are nodes

Ok, I don't know about you but switching between a command window and eclipse annoys me. Let's see what I can do about that...

Running via JUnit from eclipse

Lets see how well the promised JUnit integration actually works. It turns out that the JUnit support is all but satisfying :(

It starts ok:

package com.agical.publisher.content.site
import org.specs._
import org.specs.runner._

class PublishSiteGraphSpecTest extends JUnit4(PublishSiteGraphSpec)
object PublishSiteGraphSpec extends Specification {
  "directories are nodes" in {}
}

All I have to do is to add a class that extends JUnit4. I don't find this much more annoying than having to add the @Runwith(Theories) annotation in JUnit4 when testing with theories.

Now to the ugly part:In order to be able to select your JUnit4 classes, you need to add the output directory of your project to your build path:

1. Select your project
2. Go to "Build Path / Configure Build Path"
3. In the "Libraries" tab, "Add Class Folder"
4. In the "Class Folder Selection" dialog, do "Create New Folder"
5. In the "New Folder" dialog, select "Advanced" and "Link to folder in the file system"
6. Select the output folder of your project
7. Refresh your project (F5 on the project's folder)

You should now be able to select the JUnit4 classes of your Scala project.

Quite a turnoff but...

It works!!!

But when I try to run builder again the following error greets me:

Compiling publisher:scala-core:test into /home/jocke/dev/publisher/scala-core/target/test/classes
NoClassDefFoundError: junit/framework/Test
rake aborted!
junit/framework/Test

Obviously I have forgotten to put JUnit on the test-classpath. Said and done:

test.compile.with [JUNIT4, SPECS]
test.with [JUNIT4, SPECS, LOGBACK]

But the error is still there!!! This is kind of bad, people have enough resistance to automatic specification and tests as it is, getting them to run should be easy!

Ok, I am curious, what is going on here? Running Buildr with --trace gives the following extra information:

** Execute publisher:scala-core:test:setup
** Execute publisher:scala-core:test
NoClassDefFoundError: junit/framework/Test
** Invoke publisher:scala-core:test:teardown (first_time)
** Execute publisher:scala-core:test:teardown
rake aborted!
junit/framework/Test
/var/lib/gems/1.8/gems/buildr-1.3.2/lib/buildr/java/test_frameworks.rb:68:in `method_missing'
/var/lib/gems/1.8/gems/buildr-1.3.2/lib/buildr/java/test_frameworks.rb:68:in `filter_classes'
/var/lib/gems/1.8/gems/buildr-1.3.2/lib/buildr/java/test_frameworks.rb:363:in `tests'
/var/lib/gems/1.8/gems/buildr-1.3.2/lib/buildr/core/test.rb:423:in `run_tests'
/var/lib/gems/1.8/gems/buildr-1.3.2/lib/buildr/core/test.rb:196:in `initialize'

Ok, not that it tells me a lot but I bet that peeking into test_frameworks.rb will. It does not show in this blog but days have passed and I have considered jst going with scala-test instead or possibly the combination of specs and scala-test but I stubbornly refuse to give up even though I should. I tell myself that I might learn a thing or two about Buildr.

After getting my hands dirty I find the following on line 308:

      # ScalaTest dependencies
      DEPENDS = ["org.scalatest:scalatest:jar:#{VERSION}"] +
                 JMock::REQUIRES +
                 ScalaSpecs::REQUIRES +
                 ScalaCheck::REQUIRES

A simple

+  JUnit::REQUIRES

Solves the issue:

Running tests in publisher:scala-core
Running java com.agical.publisher.content.site.PublishSiteGraphSpec
Specification "PublishSiteGraphSpec"
  specifies
  + directories are nodes
Total for specification "PublishSiteGraphSpec":
Finished in 0 second, 72 ms
1 example, 0 assertion, 0 failure, 0 error

And I can go on to make the specification fail.

Up until this part phasing over to Scala has been a smooth ride. Specs offered some ugly hack to make it work in eclipse,but it woks. Buildr gave me a really hard time and I spent hours literally before I decided it was time to patch Buildr itself. Buildr has on the other hand been a very friendly companion up until this time and I assume that the combination Buildr, Scala, Specs + JUnit has been that common so far. On the other hand, if this was ant or maven I would have had a much harder time patching the tool. It makes a certain kind of sense to build with a dynamic language, to me anyway.

In the next part we will make our specification fail.

I'll leave you with that until next time...

In our project, we are interested in doing specific things if a test has failed. For the purposes of demonstration, lets suppose that we want to output the test name to the console when a test fails (using a method annotated with @After). How do we know whether a test has failed or not? We can access this information by using a custom test runner that extends the JUnit4ClassRunner (in JUnit 4.4), like this one ...

public class MyTestRunner
   extends JUnit4ClassRunner
{
   private static String
     failureMessage = null;

   public static String getFailureMessage() {
      return failureMessage;
   }

   public MyTestRunner(Class klass)
      throws InitializationError
   {
      super(klass);
   }

   public void run(final RunNotifier notifier) {
      failureMessage = "";
      notifier.addListener(new FailureListener());
      super.run(notifier);
   }

   private class FailureListener
      extends RunListener {

      public void testFailure
        (Failure failure) throws Exception {
           failureMessage = failure.getTestHeader();
        }
      }
}

Our runner (above) overrides the run method (only) so that we can add a FailureListener to the RunNotifier. As per the observer pattern, our notifier will call the testFailure method if the test fails, thereby setting the failureMessage. We can access the failure message from our @After method like this...

@RunWith(MyTestRunner.class)
public class MyClassTest
{
   @After
   public void printRunStatusMessage()
   {
      if (!MyTestRunner.getFailureMessage().equals(""))
         System.out.println(MyTestRunner.getFailureMessage());
      else
         System.out.println("Test did not fail");
   }

   @Test
   public void shouldAssertTruth() throws Exception
   {
      assertEquals(true, false);
   }
}

Note that our test class is annotated with @RunWith(MyTestRunner.class) - meaning that we are running the tests using our custom runner. If we go ahead and run the shouldAssertTruth test we get this line printing to the console "shouldAssertTruth(com.thoughtworks.blogdemo.test.MyClassTest)". Ta da!

In the migration to JUnit 4.5, we discovered that JUnit4ClassRunner is now deprecated. It has been replaced with the new BlockJUnit4ClassRunner. According to the JUnit API documentation the BlockJunit4ClassRunner "should have exactly the same behavior as the old test class runner (JUnit4ClassRunner)". By simply substituting the old runner class with the new one and re-executing the shouldAssertTruth test we get (drumroll) "Test did not fail" output to the console... hmm, that's not expected....

In JUnit 4.4 there are calls to an addFailure method scattered throughout the code that executes the @Before, @Test and @After annotated methods for each test. This is what the addFailure method looks like:

protected void addFailure(Throwable e) {
   fNotifier.fireTestFailure
      (new Failure(fDescription, e));
}

This method lets us know immediately when a test has failed and is the reason why our custom runner worked so well. In JUnit 4.5 we now have the concept of Statements, and without going into detail about them, JUnit now has a RunAfters class. This class is used when we want to run a test and execute its associated @After methods. The class looks like this...

public class RunAfters extends Statement {
   private final Statement fNext;
   private final Object fTarget;
   private final List fAfters;

   public RunAfters(Statement next,
      List afters,
      Object target) {
         fNext= next;
         fAfters= afters;
         fTarget= target;
   }

   @Override
   public void evaluate() throws Throwable {
      List fErrors = new ArrayList();
      fErrors.clear();
      try {
         fNext.evaluate();
      } catch (Throwable e) {
      fErrors.add(e);
      } finally {
         for (FrameworkMethod each : fAfters)
            try {
               each.invokeExplosively(fTarget);
            }
            catch (Throwable e) {
               fErrors.add(e);
            }
         }
      if (fErrors.isEmpty())
         return;
      if (fErrors.size() == 1)
         throw fErrors.get(0);
      throw new MultipleFailureException(fErrors);
   }
}

We can see in the evaluate method that any errors that are thrown during the executing of the test are collected in fErrors. fErrors is used at the end of the evaluate method to create and throw a new MultipleFailureException, which will notify our FailureListener. The crucial part for us is that despite an error being thrown during the execution of a test, the @After method will always be attempted in the finally block, and at that point we are blissfully unaware that the test has failed. Hmph.

Our solution, the quickest one to restore functionality (and not use anything deprecated), has been to create a custom RunAfters class that notifies our FailureListener of any errors in the catch block (see above). It seems less than ideal to have to do this, especially since the changes to the RunAfters class are so minor. Perhaps the next JUnit version will do something else...

Note to self: This is how you can unit test abstract classes and interfaces in Java (using the Liskov substitution principle). Using a Java 5 generic for the type of the concrete class under test to avoid excessive casting seems to be a good idea. (AbstractDuckTest has the generic type T, getDuckUnderTest() returns a T, the concrete subclasses of the test case make T be the concrete tested class.)

In languages with dynamic typing, it doesn't get so complicated. If superclass attributes are accessible from classes below, you don't even need the getter. :-) Implementation becomes trivial then.

See Ward's wiki: Abstract Test Cases for a more detailed discussion, including code examples in Java.

I have read this book a few weeks ago and now I am getting started to really apply it in a project.
In the field of TDD, this book is one of the best books I have ever read.
The book is easy to ready, easy to understand and well-written.

The author divided the book in three parts:

The first one introduces the concepts/the topics: TDD and Acceptance TDD. It presents an overview of TDD, a nice tutorial that presents you TDD from the ground and even how to apply it to a working code (welcome to refactoring ). Nice introduction to ATDD.
The part is well written and will make you understand very well the concepts.

The second one tries to demonstrate how we can apply TDD in working examples, in working situations so we may say that is entirely a part dedicated to the concrete world of development.
Some key concepts here: fixtures, test doubles, web development (servlets, Spring, JSP, Velocity, Wickets), jdbc database, ORM tools like Hibernate, thread testing , concurrency testing, GUI testing (Swing), tools for GUI testing.
I think the part is a little bit exhaustive, I was getting tired trying to understand all these examples, but anyway it’s a nice reference for all of you that might be interested.

The last part deals with Agile programming /Extreme Programming and presents the concept of building
an entire application in a test-first manner with Acceptance TDD. It presents an application build
properly for such Acceptance TDD named Fit. I think that you have to read also some other books covering this topic in order to be fully documented. I think this part does not covering enough all the concepts behind “write the test first”.

It's important to mention also the appendices: they present JUnit and Easy Mock,
both are well known in the Java world (especially the first one).

I may say that I really love this book, I do not agree entirely with some concepts in the third part of the book but I think that except these points, even if I should read it 10 times I discover every time something new.

• Be responsible for test activities (plan, automate, report) of specific projects.

Job Responsibilities:

• Research and adopt new testing processes, tools and technologies.
• Document standards and practices and ensure they are introduced across the team and enforced with software engineers.
• Document test requirements specifications, design test systems and design tests.
• Document test cases and test scripts and programs using the relevant technology e.g. TestDirector or Java and other open source technologies.
• Hold bug review meetings

Qualifications for Position:

• Technical Degree
• Specific Skills Required
• Good understanding of web: http, HTML, JavaScript, Flash, Browsers
• Software development and test life cycle.
• Structured Testing background.
• TestDirector ( Quality Center ) or similar test management and defect tracking tool
• Good communication skills in English
• Willingness to work alone and with remote teams
• Must be proactive and be willing to take the lead with managing the test process over multiple international locations

Necessary Experience:

• 2+ years structured testing experience.
• Test automation experience of web applications
• JUnit experience

Desirable Experience:

• Performance/Load Testing experience is an advantage
• Experience in VBScript

laszlo_spiller@kellyservices.hu

The Normal Things

There are some elements of setup for using the parameterized test that didn't confuse me.  Let's briefly list them:

• The test class needs to be decorated with the @RunWith(Parameterized.class) annotation
• You need a public static data-providing method, decorated with the @Parameters annotation
• Each test method is decorated with @Test (as usual)

Things I Found Confusing

The Data-Providing Method's Return Type

The data-providing @Parameters method has to return a Collection<> of arrays.  Now, ever since at least Principles of Programming I & II in college, I've had trouble remembering which subscript is which when you have a multidimensional array.  So when I saw this helpful example, my brain got stuck on line 1 of what the @Parameters method was returning:

[sourcecode language='java']
return Arrays.asList(new Object[][] {
{"22101", true },
{"221x1", false },
{"22101-5150", true },
{"221015150", false }});
[/sourcecode]

I couldn't think how this would translate to my maps I wanted to run with.

The Special Constructor

When you're using the JUnit 4 parameterized test, your test class needs to have a constructor that takes one set of the parameters and stores them to fields in the test class for use during that run.  But I couldn't figure out -- should my constructor expect a Map<String, String>[]?  A Map<String, String>?

Figuring it Out

There were a few different facets that it helped me understand:

Each Element of the Collection is a set of Parameters

The reason the @Parameters method must return a collection of Arrays is because each Array holds the parameters that are needed for one test scenario.  So if my test class needed a Map, an int, and a boolean, the @Parameters method would return a collection of three-element arrays -- each array containing the parameters for one configuration of the test class.  This leads to the next facet...

The Test Class Constructor Should Accept One Parameter for Each Element of the Array

The JUnit parameterized test mechanism expects to instantiate the test class by calling a constructor that has the same number of arguments as there are elements in the current parameters array*.  If my test class FooTest needed a Map, an int, and a boolean each time, the constructor might look something like this:

[sourcecode language='java']
    public FooTest(Map map, int value, boolean flag) {
    //...
    }
[/sourcecode]

...and my @Parameters method would need to return a Collection of Arrays of Object ("of Object" since for a given array, the three elements would be of different types).

*I haven't read or tested to see if the JUnit mechanism supports a collection of jagged arrays of configuration parameters such that (for instance) sometimes the test class might be instantiated using the two-arg constructor, other times using its three-arg constructor...

Store the Parameters in Private Fields in your Test Class

What you'd normally do is store the parameters you get constructed with to private fields, for use by the @Test methods:

[sourcecode language='java']
@RunWith(Parameterized.class)
class FooTest {
private Map map;
private int value;
private boolean flag;

    public FooTest(Map map, int value, boolean flag) {
    this.map = map;
this.value = value;
this.flag = flag;
    }

//...
}
[/sourcecode]

The Application to My Case

I think I was more confused because I only needed one parameter -- a Map<String, String> -- so it wasn't apparent to me why the Collection of Object Arrays was needed.

So the "hard parts" of my test class end up looking something like this:

[sourcecode language='java']

@RunWith(Parameterized.class)

class FooTest {

    private Map map;

    @Parameters
    public static Collection configs() {
        Map map1 = new HashMap();
        map1.put("Name", "Bill");
        map1.put("Favourite Color", "Blue");

        Map map2 = new HashMap();
        map2.put("Name", "Sam");
        map2.put("Favourite Color", "Plaid");

        return Arrays.asList(new Object[][] {
                { map1 },
                { map2 }
        });

    public FooTest(Map map) {
        this.map = map;
    }

    //...
}
[/sourcecode]

(Maybe nobody else needed that explanation, but it helped me!  :)

Hi guys! Udah lama gak utak atik java karena project disini pake .NET. Kemaren malam ketika sedang nganggur dan utak atik netbeans bwat ngerefresh pikiran, saya menemukan fitur netbeans keren yaitui automated code generation untuk unit testing menggunakan framewrk JUnit . Just like Jeff Atwood said " A feature is not  a feature until some user used it ",  saya juga baru sadar kemaren klo ada fitur seperti itu di netbeans 6.1. Dengan fitur ini, developer dimudahkan untuk membuat unit test karena Netbeans akan otomatis membuat test class dan test casenya. Lets start coding for further details.

Untuk yang belum familiar dengan unit testing dan JUnit, bisa membaca artikel dibawah ini untuk pendahuluan :

• Wikipedia Entry
• Blog Pak Endy tentang ruthless testing
• Tulisan saya tentang JUnit

Mari kita mulai dengan membuka netbeans 6.1.

Buat sebuah java project baru

Gak wajib sebenarnya, cuman memudahkan aja. Lanjut ke langkah selanjutnya.

Buat class dengan return valued dan void method

Setelah mensetup project netbeans, selanjutnya kita buat class yang berisi return valued method dan void method. Tujuannya adalah melihat hasil generasi kode netbeans terhadap dua method yang berbeda tersebut. Anda juga bisa bereksperimen dengan menggunakan Main method atau method yang mereturn Object. Untuk kali ini, kita buat sangat simple saja. Sebuah class yang berisi operasi dasar matematika.

[sourcecode language='java']

public class SimpleMath {
            
        public int doAddition(int a, int b ){
                                 
            return a + b ;
        }
        public int doSubtraction(int a, int b){
                  
            return a / b;
           
        }
        public void printAddition(int a, int b){
       
                 System.out.println("var1 = "+a+" , var2 = "+b+" " +
                         "hasilnya adalah = "+doAddition(a, b));
                       
        }
    }

[/sourcecode]

Keep the class really really simple karena yang akan kita pelajari disini adalah bagaimana netbeans membuat kode test class secara automatis.

Let the magic do the test code

Pilih menu create Junit test (Tools > Create JUnit test. Setelah itu muncul dialog window yang berfungsi mengatur parameter test class yang dibuat. Setelah itu klik oke dan voila!! test class sudah otomatis dibuat di dalam folder Test Package. Anda juga dapat menggunakan keyboard shortcut Ctrl+Shift + U.

Masukkan parameter test

Edit parameter test pada test class. Sebelum menjalankan test class jangan lupa untuk meremove method fail() di masing masing method test case.

Jalankan test class

Jalankan test class pada test package. Palette netbeans unit test akan keluar dan menunjukkan apakah class SimpleMath lolos atau tidak dari unit test.

Test result palette

Mudah sekali bukan. Fitur test code generation ini akan sangat membantu karena membuat test case merupakan salah satu pekerjaan yang membosankan dan melelahkan sehingga seringkali dilewatkan oleh developer. With netbeans, its just as simple as pressing Ctrl + shift + U.

Saya juga membuat file .ppt nya in case topik ini akan dipresentasikan entah dimana (heheheh). PPT nya bisa di download di :

My Slideshare Account 
simple-java-unit-testing-with-junit-4

Sekian dulu temen temen. Have a nice coding day.

:D

Java unit testing frameworks like jUnit, TestNG with some other pretty frameworks like easy mock and easy mock class extensions help us test individual classes with mocking out the external dependent classes/resources and make the tests more "unit".

Spring out of the box supports unit testing with jUnit and TestNG. Spring provides seperate set of classes help you unit test your spring classes.

Spring 2.5 in its org.springframework.test.context package has a set of classes to have better unit testing using jUnit4.

I am about to show an example of testing a service called BlogSearchService. The service simply calls a method in the blogDAO which searches the blogs based on the keyword and return a list of blogs. So here my service class is simple, it calls the DAO. So in my test I just have to make sure that it makes a DAO call and the result is then returned to the client.

Lets see the code for BlogSearchService and BlogSearchServiceImpl,

BlogSearchService.java

BlogSearchServiceImpl.java

Here is the test case for BlogSearchService,
In the test case, the ContextConfiguration helps in specifying the config file to load. In the @Before (setup method for the test case) I am creating the instance of BlogSearchServiceImpl (but instead you can autowire it). Then I am creating the mock object of blogDAO and setting it to the BlogSearchService. In the actual test method, I expect that the searchBlogByKeyWord on the blogDAO and I am expecting it retuning no posts. You can do any asserts here depending on the actual business.

SpringJUnit4ClassRunner is a custom extension of JUnit4ClassRunner which provides functionality of the Spring TestContext Framework to standard JUnit 4.4+ tests by means of the TestContextManager and associated support classes and annotations.

It's so simple and sweet testing spring classes with jUnit and easymock. Isn't it?

Templating

Ett designmönster som används flitigt i Spring är "template method". En template-metod definierar ett skelett för en algoritm. Algoritmen är abstrakt och det är upp till subklasser att definiera det konkreta beteendet för algoritmen. Ett annat designmönster som påminner mycket om "template method" är mönstret Strategy, en av skillnaderna mellan "template method" och "Strategy" är att "template method" använder arv medan Strategy-mönstret använder delegat för att uppnå sitt mål. Nedanstående visar användningen av Strategy-mönstret via ett exempel som är kraftigt influerat från ett wikipedia-exempel som använder template method.

/** A game that can be played... */
public interface Game {
    void initializeGame();
    void makePlay(int player);
    boolean endOfGame();
    void printWinner();
} 

/** Concrete implementation of the chess game... */
public class Chess implements Game {
    public void initializeGame() {
        // do chess stuff...
    } 

    public void makePlay(int player) {
        // do chess stuff...
    } 

    public boolean endOfGame() {
        // do chess stuff...
        return false;
    } 

    public void printWinner() {
        // do chess stuff...
    }
} 

/** Concrete implementation of the monopoly game... */
public class Monopoly implements Game {
    public void initializeGame() {
        // do monopoly stuff...
    } 

    public void makePlay(int player) {
        // do monopoly stuff...
    } 

    public boolean endOfGame() {
        // do monopoly stuff...
        return false;
    } 

    public void printWinner() {
        // do monopoly stuff...
    }
} 

/** The class containing the template method. */
public class GameTemplate {
    /**
     * This is a template method that plays the provided
     * game using a specified algorithm (initialize,
     * play, end, print winner)
     *
     * The template method is common to several games in
     * which players play against the others, but only one
     * player is playing at a given time.
     */
    public void play(int playersCount, Game game) {
        game.initializeGame(); 

        int j = 0;
        while (!game.endOfGame()){
            game.makePlay(j);
            j = (j + 1) % playersCount;
        } 

        game.printWinner();
    }
}

Exemplet ovan visar hur en algoritm appliceras på ett Game-objekt i metoden play. Exemplet är en aning förändrat jämfört med originalet så till vida att klassen GameTemplate inte är ett Game utan endast innehåller själva algoritmen för att få en lösare koppling mellan algoritmen och de faktiska Game-objekten.

Nu när vi känner till designmönstret "template method" kan vi kika vidare på templaten som tillhandahålls av Spring för JDBC-relaterade operationer, nämligen JdbcTemplate.

JdbcTemplate

Klassen JdbcTemplate är kärnan i den modul som kallas spring-jdbc. Klasserna i denna modul används när access till databasen sker via JDBC snarare än via ett O/R-mappningsramverk såsom Hibernate.

Att använda rå JDBC kan medföra en hel del problem för utvecklaren där Connections, Statements, ResultSets måste stängas, exceptions måste fångas osv. Kod som är skriven för rå JDBC-användning är ofta väldigt utförlig (verbose) och leder lätt till fel (såsom att glömma att stänga ett statement). Springs JdbcTemplate hjälper utvecklaren med många delar av de uppgifter som krävs för att använda JDBC.

Tabellen ovan visar de delar som JdbcTemplate hjälper dig med jämfört med att använda rå JDBC.

Nedanstående exempel visar vanlig användning av rå JDBC med en enkel parameteriserad SELECT och en mappning mellan ett Person-objekt och ett ResultSet.

private static final String PERSON_QUERY =
        "select first_name, last_name, phone_number "
        + "from person where last_name = ?"; 

public List getPersonList1() {
    List list = new ArrayList();
    Connection connection = null;
    PreparedStatement statement = null;
    try {
        connection = getConnection();
        statement = connection.prepareStatement(PERSON_QUERY);
        statement.setString(1, "Svensson");
        ResultSet rs = statement.executeQuery();
        while (rs.next()) {
            Person person = new Person(
                rs.getString("first_name"),
                rs.getString("last_name"),
                rs.getString("phone_number"));
                list.add(person);
        }
        rs.close();
    } catch (SQLException e) {
        // handle exception somehow...
    } finally {
        if (connection != null) {
            try {
                connection.close();
            } catch (SQLException e) {
                // handle exception somehow...
            }
        }

        if (statement != null) {
            try {
                statement.close();
            } catch (SQLException e) {
                // handle exception somehow...
            }
        }
    }

    return list;
}

Exemplet kan förenklas avsevärt genom användning av JdbcTemplate vilket metoden getPersonList2 i nedanstående exempel visar.

public List getPersonList2 () {
    RowMapper personMapper = new RowMapper() {
        // Maps a row to a Person
        public Object mapRow(
                ResultSet rs,
                int rowNum) throws SQLException {

            return new Person(
                rs.getString("first_name"),
                rs.getString("last_name"),
                rs.getString("phone_number"));
        }
    };

    return getJdbcTemplate().query(
        PERSON_QUERY, new Object[] {"Svensson"}, personMapper);
}

Vi antar i exemplet ovan att man kan få tag på en JdbcTemplate via metoden getJdbcTemplate().

Några saker värda att notera:

• Kod för att hantera connections, statements etc. saknas helt. Detta hanteras av JdbcTemplate som öppnar och stänger alla resurser.
• Mappning mellan SQL-resultatet och affärsobjektet sker i en RowMapper. Detta är ett tydligt mönster och RowMapper-objektet kan återanvändas om det deklareras utanför metoden. Förutom RowMapper finns även andra sätt att mappa data och dessa kan återfinnas i Springdokumentationen.
• Ingen felhantering krävs. Alla eventuella exceptions fångas av JdbcTemplate och konverteras sedan till Springs egna unchecked exceptions mha. SQLExceptionTranslator. Istället för att kasta ett checked exception med en kryptisk databasunik felkod kan tydliga exceptions såsom BadSqlGrammarException eller OptimisticLockingFailureException kastas. De databaser som supportas out-of-the-box är DB2, Derby, H2, HSQL, Informix, MS-SQL, MySQL, Oracle, PostgreSQL och Sybase. Naturligtvis går det även att plugga in egna SQLExceptionTranslators.

Det finns även några inbyggda RowMappers. Metoden queryForInt som exemplifieras nedan skapar en intern RowMapper där ett SQL-resultat mappas mot ett heltal.

public int countPeople() {
    return getJdbcTemplate().queryForInt(
            "select count(*) from person ");
}

I exemplen ovan har endast SELECT-frågor mot databasen ställts. Det finns även metoder för att utföra uppdateringar, se exemplet nedan för en enkel parameteriserad uppdatering:

private static final String UPDATE_PERSON =
    "update person set phone_number = ?"
    + "where first_name = ? and last_name = ?";

public void updatePhoneNumber(
        String firstName, String lastName, String phoneNumber) {

    getJdbcTemplate().update(
            UPDATE_PERSON,
            new Object[] {phoneNumber, firstName, lastName});
}

JdbcTemplate behöver endast konfigureras upp med en datakälla. Det finns några bekväma klasser att ärva från för att enkelt få tag på JdbcTemplate-objektet. Klassen JdbcDaoSupport kan användas för DAO-objekt medan klassen AbstractTransactionalDataSourceSpringContextTests fungerar bra för JUnit-tester. Nedanstående exempel visar detta.

Så här kan en DAO-klass se ut:

public class MyDao extends JdbcDaoSupport {
    private static final String UPDATE_PERSON =
        "update person set phone_number = ? "
        + "where first_name = ? and last_name = ?";

    public void updatePhoneNumber (
            String firstName, String lastName, String phoneNumber) {

        getJdbcTemplate().update(
                UPDATE_PERSON,
                new Object[] {phoneNumber, firstName, lastName});
    }
}

När en DAO konfigureras så måste en DataSource injectas, detta kan exempelvis ske via en JNDI-uppslagning:

<bean
  id="myDataSource"
  class="org.springframework.jndi.JndiObjectFactoryBean">

    <property name="lookupOnStartup" value="false" />
    <property name="proxyInterface" value="javax.sql.DataSource" />
    <property name="resourceRef" value="true" />
    <property name="jndiName" value="jdbc/myds" />
</bean>

Själva DAO-objekten kan exempelvis deklareras i en egen fil som kan användas både för produktion och för test.

<bean id="myDao" class="se.cygni.sample.spring.template.jdbc.MyDao">
    <property name="dataSource" ref="dataSource" />
</bean>

När applikationen ska konfigureras för test så kan en DataSource konfigureras utan JNDI-uppslagning:

<bean
  id="myDataSource"
  class="org.springframework.jdbc.datasource.DriverManagerDataSource" >

    <property name="driverClassName"
        value="oracle.jdbc.driver.OracleDriver" />
    <property name="url" value="jdbc:oracle:thin:@host:port:schema" />
    <property name="username" value="scott" />
    <property name="password" value="tiger" />
</bean>

Ett JUnit-test kan se ut enligt följande:

public class MyDaoTest
        extends AbstractTransactionalDataSourceSpringContextTests {

    private MyDao dao;

    protected String[] getConfigLocations() {
        return new String[] {
                "testDataSourceContext.xml",
                "daoContext.xml"
        };
    }

    public void testDao() {
        dao.updatePhoneNumber("Johnny", "Puma", "555-555 5555");

        int count = getJdbcTemplate().queryForInt(
            "select count(*) from person "
            + "where first_name = 'Johnny' "
            + "and last_name = 'Puma' "
            + "and phone_number = '555-555 5555'");

        assertTrue(count == 1);
    }

    public void setMyDao(MyDao dao) {
        this.dao = dao;
    }
}

I testet ovan visas hur dels MyDao injectas i testklassen eftersom filen daoContext.xml anges som en config-location. Även filen testDataSourceContext.xml inkluderas vilket leder till att en DataSource finns tillgänglig och då injectas denna DataSource i basklassen AbstractTransactionalDataSourceSpringContextTests vilket leder till att metoden getJdbcTemplate blir tillgänglig i testfallet.

Det finns även stöd för Java 5 i Springs JDBC modul. Genom att ärva klassen SimpleJdbcDaoSupport istället för JdbcDaoSupport i din DAO kan Java 5 metoder användas via klassen SimpleJdbcTemplate. Se exemplet nedan.

public List<Person> getPeople() {
    ParameterizedRowMapper<Person> rowMapper =
        new ParameterizedRowMapper<Person>() {
            public Person mapRow(ResultSet rs, int rowNum)
                    throws SQLException {

                return new Person(
                        rs.getString("first_name"),
                        rs.getString("last_name"),
                        rs.getString("phone_number"));
            }
    };

    return getSimpleJdbcTemplate().query(
            "select first_name, last_name, phone_number from person",
            rowMapper);
}

För mer information om Spring och JDBC rekommenderas Springdokumentationen och JavaDoc för JdbcTemplate.

With around 20 sessions running in parallel for each slot during the conference, it was kind of difficult to choose the session to attend. It was interesting that most of the sessions I went to were small ones, attended by only about 10-12 people and therefore quite interactive. Overall, they were also quite technical in their content and therefore captivated my interest. While talking about it within the team after my return, Uros made an insightful comment, "It sounds like you are more interested in the applied engineering aspects of Agile than the tools and practices". I had never thought of it that way but on retrospect, that sounds about right.

I could provide a listing of all the talks I attended but that sounds like overkill. Instead, I will focus on my top three picks:

TDD in Concurrent Applications by Brett Schuchert & David Nunn

This was definitely one of the highlights of the conference for me. It became apparent within the first 15 minutes of this 3-hour session that none of the attendees was a novice at understanding and writing concurrent applications, so the session moved on to more advanced discussions quite quickly. While most of the concepts were general, most of the code we looked at was in Java. The two most important bits of advice I took from the session that it is important to actually understand (and read) bytecode to truly understand concurrent code and of the existence of a tool called ConTest which can be used to introduce delays between the execution of consecutive bytecode instructions, thereby increasing the probability of highlighting concurrency issues while testing. Both Brett and David were very impressed by our implementation of an optimistic concurrency control system within our code!

Pomodoro Technique by Staffan Noteberg

This was one of the rare slots when I couldn't find anything obviously appealing, so I thought I would try something different. Turned out that going in with an open mind and no prejudices worked well for me and I was able to buy into the idea enough to warrant a trial of it - hopefully sooner rather than later. Essentially, it is a technique that helps you stay focussed on one task for short periods of time, thus enabling you to achieve measurable amounts of work every day. I could clearly see the transposition of the Agile sprint / story idea into a smaller scale, and definitely seems worth a try.

BDD using JUnit by Dan North & Elizabeth Keogh

This was my very first session of the conference and it left me feeling positive for the rest of the week. I hadn't realized before the session that Dan was one of the founders of BDD. It was interesting to hear about the origins of BDD and to see a good pairing session which drove home most of their ideas. As an aside, I also found some useful things about JUnit4.4 and the Mockito framework. Enough that I would like to try and incorporate them into some real code soon for some first-hand experience.

La fase testing dovrebbe in teoria iniziare non appena i requisiti della applicazione sono stati definiti e dovrebbe poi continuare per il tutto il processo di sviluppo poichè all'aumentare della complessità della applicazione i test devono garantirne il suo funzionamento e, dunque, esistono diversi livelli di test da quelli di unità a quelli di sistema e validazione (acceptance test).

Indipendentemente dai livelli esistono test di varia natura da quelli funzionali a quelli di robustezza e performance. In sostanza come avete potuto capire il tutto puo' richiedere abbastanza tempo e quindi se si cerca di rendere quanto più automatica questa fase è meglio.

Nel mondo Java il tutto inizia con le librerie di Junit. Rilasciate con licenza Common Public Licence 1.0 sono arrivate, al momento in cui scrivo, alla versione 4.5 (del 8/8/2008). Esse permettono di automatizzare la fase di testing scrivendo metodi che contengono alcune chiamate alle librerie e tra queste esistono i metodi "assertEquals()" che verificano che 2 oggetti (quello atteso e quello di cui si dispone) sono uguali (da cui poi tuttte le derivazioni come il confronto tra booleani, stringhe ecc.).

Nonostante siamo alla versione 4.x la serie precedente, 3.x, viene mantenuta questo perchè le classi che contengono i metodi devono essere opportunamente scritte, in particolare con la 3.x ad esempio i nomi dei metodi devono avere una certa struttura (testXXX, cioè devono iniziare per test) mentre la 4.x permette di avere una certa elasticità usando pero' le annotazioni come javadoc. Eclipse 3.4 annovera tra le sue librerie sia Junit 3 (3.8.2) e Junit 4 (4.3.1) e permette di creare Test case usando l'una o l'altra libreria. In questo esempio vedere come creare Junit Test case con la versione 4.

Un'ultima cosa che dovete sapere su Junit è che potete raggruppare i Test case in Test suite che eseguono più test. Inoltre quando si scrivono metodi per i test può capitare che questi condividano degli oggetti inizializzati; Junit permette di inizializzare, e poi distruggere, risorse condivise tramite i metodi setUp() e tearDown(), vi lascio poi scoprire il tutto facendovi spulciare la documentazione.

Ant, non solo vi permette di automatizzare il tutto con il suo Junit task, ma vi crea anche, a partire dai risultati di ogni test, dei sempli report.

Quando create dei web services usando il plugin di Axis2, Codegen Wizard, per Eclipse probabilmente avrete notato l'opzione che genera anche i test cases che alla fine non sono altro che semplici client che dovete inizializzare dando l'end point da contattare e costruendo gli oggetti che da passare allo stub. Inoltre potete modificare il file Ant generato per generare i report che vi avevo accennato prima.

Junit è pero' la punta di un iceberg. Difatti si sono evolute applicazioni che si occupano solo della fase di testing come Cactus, Fitnesse (che è un wiki che fa acceptance test) , Selenium che allargano l'orizzonte anche alle applicazioni web, lo stesso Spring tra l'altro contiene un modulo per il testing. Se poi parliamo di performance esiste jMeter (a cui SOAPUI fa concorrenza).

SoapUI è una applicazione rivolta ai web services che abbiamo già incontrato quando vi ho accennatto alla possibilità di validare i file wsdl per migliorare l'interoperabilità.

Una delle funzionalità carine è quella di creare al volo una richiesta SOAP automaticatimente generata a partire dal file wsdl, generando poi report e test di copertura su file wsdl.

Junit non è poi l'unico testing framework esistono TestNG ed anche Nunit (che è il porting di Junit per .NET) e una miriade di applicazioni che vengono usate per testare i vari linguaggi.

A questo punto vi auguro buona esplorazione in questo mondo che, anche per me, si sta rivelando sempre più grande e al tempo stesso affascinante (soprattutto come sviluppatore pigro che vorrebbe automatizzare tutto ciò :-) ).

P.S: Occorre dire che lo stesso Eclipse nel suo piccolo permette di testare on-line il servizio web. Difatti cliccando con il tasto destro del mouse sul file wsdl dovreste ritrovarvi nel menu contestuale la voce Web Services da cui la sotto voce Test with Web Services Explorer che è una interfaccia web che vi permette di compilare i campi  da mandare nella richiesta SOAP e subito sotto vedere la risposta.

Link interessante: http://wso2.org/library/3862

Alla prossima