Tag: java

TSSJS2011: How to Reap the Benefits of Agile-Based TDD

I attended a breakout session on jQuery right after lunch, but I didn’t have my laptop up and, honestly, it was a pretty high-level presentation of jQuery in any case.   The technology certainly looks promising and I’ll have to find a way to play with it one of these days.   Then again, I’m still trying to play with Scala and Mule, technologies I heard and read about after last year’s TSSJS.   Aaaah…. where does the time go?

Agile based TDD sounds like a good session.   As much as I keep wanting to move to TDD, I have a really difficult time doing so.   Hopefully the more exposed I am to it, the easier it’ll become to actually use the methodology.

What is TDD?
Test-Driven Development is a software development process.

The TDD Process:
1.  Write a failing test for the target behavior
2.  Implement the behavior as simple as possible to get the test to pass
3.  Refactor the implementation

TDD is a Design Activity

TDD treats Tests as VIP Artifacts:  You need to treat your tests as first-class citizens

TDD is an “Agile” Practice:
1.  Working software is the primary measure of progress
2.  Continuous Attention to technical excellence and good design enhances agility
3.  Welcome changing requirements, even late in development

Types of Tests:
1.  Unit Testing: Verification of Design
2.  Acceptance Testing:  Verification of Features

What is a Unit Test?
Exercises a small testable piece of software
Tests a specific object behavior in isolation
Assumes that external dependencies work according to their contracts
Defines the assumptions that can be made of the target unitHow is unit test independent of its dependencies?  Mock Objects

Tools and Frameworks

JUnit
Openpojo:  a framework for validating that POJOs are adhering to a standard contract
Mockito:  Mocking Framework – Declare dependencies with @org.mockito.Mock

The Benefits of TDD

Test-Driven Development improves Design

SOLID Design
* Single responsibility principle: Can do one thing really well, loosely coupled
* Open/close Principle: Encapsulation – What, not how?
* Liskov substitution principle: Contract  first Design.  Avoid inheritance unless “is a” …
* Interface Segregation Principle: Interface clients should only depend on methods they need
* Dependency Inversion Principle: Depend on Abstractions instead of mocking

TDD Follows Law of Demeter

TDD avoids Static Helper Classes:  Procedural programming, not OO programming.

TDD Measures Progress, provides Documentation, and provides code coverage

How to Make it Work

* Flip Your Perspective – become a user, not a developer
* Always See Your Test Fail – make sure your tests have clear messages
* Listen to Your Tests – Urge to share test fixture state, setup, … => need to refactor
* Use an Interface Driven Approach
* Learn it well – TDD by Kent Beck

KATA

TDD Kata – Exercise in coding, refactoring and test-first, that you should apply daily for at least 15 minutes.  -Roy Osherove

http://www.osherove.com/tdd-kata-1/

TSSJS2011: Do You Really Know Class Loaders?

I’m back at The Server Side Java Symposium this year and this is the first breakout session I’m attending.   I think I’ve got good knowledge of ClassLoaders and Java Reflection API, but we’ll see if Jevgeni Kabanov, the speaker, can enlighten me with some new nuggets of knowledge.   He’s Founder & CTO of ZeroTurnaround, a company I know next to nothing about, although I have heard of JRebel, one of their products.   Anyway, enough background info… Let’s jump into the meat of the presentation.

Basics

public class A {
    public void do() {
        B b = new B();
        b.do():
    }
}
Instantiating Object B causes the following:  A.class.getClassLoader().loadClass("B");

Problems & Solutions

1. Class Not Found
You build some code and get a NoClassDefFound exception when deploying and trying to run the servlet.   How do we find out what the problem is?

Some solutions:
* IDE Class Lookup
* find *.jar -exec jar -tf ‘{}’ \; | grep MyClass
* URLClassLoader.getURLs()

2. Wrong Class Found
What if you get a NoSuchMethodError?  What’s happening there?  Well, the Class is found, but there’s something wrong with the class.

Solution:
* Get ClassLoader().getResource(Util2.class.replace(‘.’,’/’) + “.class” to find out where the ClassLoader is getting the class.  Then you can use javap -private Util2 to inspect the contents of the file.

3. More than One Class Found
 That error will typically occur if 2 different ClassLoaders are used and find different classes for the same name.   They are not the same.

Helpful:  -verbose:class, as well as ClassLoader.getResource() to identify the different classes.

Leaking ClassLoaders

If a Class has a reference to its ClassLoader, that object has a reference to all of its classes.    To leak a ClassLoader, it’s enough to leak just one object loaded by that ClassLoader.

Hierarchy is not enough?

* Isolation: Difference versions of the same library
* Performance: Class lookup is very slow
* Restricted: Why can’t siblings see each other’s classes?
* OSGI, JBoss, NetBeans and others implement a different system

Follow the speaker on Twitter: @ekabanov