Tale of a test driven challenged programmer.

[Pavan Kumar]

Hello All,

Here's my story.
This is my 3rd attempt to drive the code that I write with unit tests. and I'm still not getting the habit of it. Although, this time I'm a little more determined to get myself sticking to it, often I'm finding myself writing tests after I write code. This is at least better than not writing tests at all, but I realize that I'm not getting the full benefits of writing the tests first.

The biggest disadvantage that I'm seeing in writing tests after is, I'm ending up taking bigger steps. as a result, I think, my code is quickly becoming non testable. When I get it right though, I feel a lot happier about my code. A lot confident, actually. One thing that's putting me off from running the tests after I finish coding, before running the program to check the output, is that when a test fails, if I click on the stack trace -- it does not take me to the source. Again, not going in small increments is actually the problem - I think.

I'm using Junit to write my tests, and Eclipse as my editor. If you have any suggestions to improve my test driving skills, I would be very thankful if you share a few. I appreciate any suggestions for a book as well.

Thanks for your attention.

Best,
Cnu

[Ilja Preuss]

Practice, practice, practice... And, yes, learning to take tiny little steps is key.

Take a look at https://coderanch.com/t/419376/patterns/OO-design - some posts down on the first page, Frank and I start to pair program on test driving a tennis scoring program, and you can see every tiny single step we take.

Kent Beck's "Test Driven Development - By Example" is a good introductory book. I didn't yet take a look at the book of Lasse Koskela, our esteemed co-Sheriff, but I've heard good things about it, too!

[Lasse Koskela]

Perhaps we should walk through the steps you're taking through a concrete example? It's hard to give good advice without understanding the context.

Regarding book recommendations, I would recommend this and this. The latter was written by yours truly so you might want a second opinion, though

[Ilja Preuss]

Originally posted by Lasse Koskela:

Regarding book recommendations, I would recommend this and this. The latter was written by yours truly so you might want a second opinion, though

Great minds thing alike...

[Pavan Kumar]

Hello Ilja and Lasse,

Thanks very much for the book recommendations, I've placed an order for both of those books. Hoping the books will teach me to the right techniques to embrace test driven development.

Here's a sample code that I've had some tests for. The initial version of my code implementation was not as it's shown right now. After a few refactorings, I've arrived at the current state. It's still not very generic, as for example-- the method splitCollection is very specific and handles only Collection of String objects, but I'm reasonably happy with it's current state. As I am able to separate splitting of a collection, and turning a collection of String objects into a String substitutable to SQL IN clause. The first implementation was doing all of that in one single method and not very elegant. Like I mentioned in my previous post, the tests were written after the code has been written.

Here's my code, Any inputs are greatly appreciated. Again, thanks very much for taking a look at this.

Cnu.

  
public class ApplicationUtils {
 
public static String collectionToInClause(final Collection<String> collection) {
if (collection == null || collection.isEmpty() ) {
return "";
}
StringBuilder buffer = new StringBuilder();
for (Iterator<String> iter = collection.iterator(); iter.hasNext() :wink:  {
String element = (String) iter.next();
buffer.append("'");
buffer.append(element);
buffer.append("'");
if (iter.hasNext()) {
buffer.append(",");
}
}
return buffer.toString();
}

public static List<Collection<String>> splitCollection(final Collection<String> source, final int batchSize){ 
        List<Collection<String>> result = new ArrayList<Collection<String>>(); 
        if( source == null  ){ 
                return result; 
        } 
        if( batchSize > source.size() || batchSize == 0 || batchSize == 1 ){ 
                result.add(source); 
                return result; 
        } 
        List<String> list = new ArrayList<String>(batchSize); 
        for (String entry : source) { 
                list.add(entry); 
                if( list.size() == batchSize ){ 
                        result.add(list); 
                        list = new ArrayList<String>(batchSize); 
                } 
        } 
        if( ! list.isEmpty() ){ 
                result.add(list); 
        } 
        return result; 
} 
 
}
 

public class StringCollectionToInClause {
@Before
public void init(){

}
 
@Test
public void testCollectionToInClause() {
final int size = 100;
List<String> list = new ArrayList<String>();
for (int i = 0; i < size; i++) {
list.add("abc-" + i);
}
String inClause = ApplicationUtils.collectionToInClause(list);
System.out.println(inClause);
String[] splits = inClause.split("\\,");
System.out.println("Total Splits --> " + splits.length);
System.out.println("Splits == size "+ ((splits.length == size) ? "Yes" : "No"));
Assert.assertNotNull("In Clasue is not null "+inClause);
Assert.assertTrue("Assert The Collection Size and InClause splits lenght equal",(size==splits.length));
}
@Test
public void splitCollectionAndTurnInToInclauseSubstitutables(){
final int size = 100;
final int batchSize = 12;
List<String> list = new ArrayList<String>();
for (int i = 0; i < size; i++) {
list.add("abc-" + i);
}
List<Collection<String>> batches = ApplicationUtils.splitCollection(list, batchSize);
System.out.println("The collection should have been split into "+Math.ceil((double)size/batchSize)+" --> "+batches.size());
Assert.assertEquals(Math.ceil((double)size/batchSize), (double)batches.size());
int cumulativeBatchSize =  0;
for (Collection<String> batch : batches) {
cumulativeBatchSize += batch.size();
}
System.out.println("Souce Collection size -->"+size+" All Batches size -->"+cumulativeBatchSize);
Assert.assertEquals("Compare Total size of all batches to the source collection size",size, cumulativeBatchSize);
}

@After
public void cleanUp(){

}
}
 

[Jeanne Boyarsky]

Cnu,
A few things jump out at me that could be improved:
1) Both tests have a loop that creates a 100 element array containing "abc...". This could go in the @Before to avoid duplication.
2) The System.out.println() statements are an antipattern. Anything that you are checking by hand could be an assert. For example, consider the following. If the size is not equal to the length, there is a problem and the test should fail. JUnit can do it automatically. If you are waiting for a human to look and notice something is wrong, this is error prone. And as you get more tests, a human is less and less likely to notice. (I now realize this is asserted later. So what does the println buy you?)
System.out.println("Splits == size "+ ((splits.length == size) ? "Yes" : "No"));
3) I recommend using assertEquals("message", size, splits.length) rather than
assertTrue("Assert The Collection Size and InClause splits lenght equal",(size==splits.length));
The former will give you a clearer message if the assert fails as it will tell you what the expected/actual values were. It's nice not to have to use the debugger when this happens.

I also notice that the tests don't cover all the possible scenarios. This is the kind of thing that doesn't happen when writing the tests first .

[Pavan Kumar]

Hello Jeanne,

Thanks very much for your inputs.
I've moved the construction of ArrayList with test objects to init() method, and removed duplicate code.

The print statements, I think they are more from habit than for any reason. Specially When I wanted to validate the test results, for instance if I wanted to look if the in clause is being constructed properly or not. With a little bit more experience and form, I think I should do away with the print statements.

Thanks for the assertEquals suggestion. I noticed when I use this method, if a test fails, it does print whatever I have in the String argument of the method --this is very useful information with both expected and actual values are printed.


Thanks,
Cnu

[Nicholas Jordan]

[original poster:]   Any inputs are greatly appreciated. Again, thanks very much for taking a look at this.

Well what I did before coming to Java was decide on any real-world program that interested me and that led immediately to thinking of a way to thwart intruders, and doing so in the interest of a customer. Someone who had some reason to protect something and I would have to do it for them in code.

That got me motivated and remains today a design challenge that continues to be interesting and motivating. Anything you are interested in will be of use in keeping motivated. To design by test first, you have to have some reason to test-first, and that usually has to be some sort of difficulty which can and will ensue if something does not happen. Thus, the design of the test is rather easy and forthcoming to protect square inches of hide and reputation.

You state any inputs, that is my input.

[Jeanne Boyarsky]

Originally posted by cnu sri:
The print statements, I think they are more from habit than for any reason. Specially When I wanted to validate the test results, for instance if I wanted to look if the in clause is being constructed properly or not. With a little bit more experience and form, I think I should do away with the print statements.

I think you will do away with them as well. One tip on this: whenever you are tempted to write a println, think about what you want to manually verify. Then write an assert on that instead.

I do have one use for printlns. There's a test pattern called the "golden master." It means that you say the current implementation is correct and you want to be told if something changes. I like using it for some SQL statements. I will use a println to get actual, copy it to a variable, assert it as expected and then remove the println. The println never makes it to version control.

[Cedric Beust]

Hi Pavan,

Coming in a bit late, but that's actually the point of my question to you.

One month after your original post and, I assume, after reading these books, would you say that you are now happily using TDD in your daily routine or are you still stuck?

--
Cedric

Originally posted by Jeanne Boyarsky:

I think you will do away with them as well. One tip on this: whenever you are tempted to write a println, think about what you want to manually verify. Then write an assert on that instead.

I do have one use for printlns. There's a test pattern called the "golden master." It means that you say the current implementation is correct and you want to be told if something changes. I like using it for some SQL statements. I will use a println to get actual, copy it to a variable, assert it as expected and then remove the println. The println never makes it to version control.

[Pavan Kumar]

Hello Cedric,

Thanks very much for looking into this thread.
I'd say I haven't made as much progress as I'd have liked, but I think I'm progressing a little slower but trying.

At this point,I'm of the opinion that good programmers write testable code, and I'm realizing that my test driving ability is mostly hampered by my code that's non testable. I'm still taking relatively larger steps when compared to the steps that have been shown in Kent's book. But this is going to take some time and more practice.

I've really done myself a favor by buying Lasse's book, Although I've read Unit Testing By Example the fastest, I think I'll be gaining much more to read it after I've read Lasse's book.

I'll be watching all the activity here for any inputs as well.

Thanks,
Pavan

[Cedric Beust]

Hi Pavan,

For what it's worth, I believe that as you become more comfortable with writing testable code, whether you write your tests first or last doesn't really make that much of a difference: at the end, you still have code that's easy to test and tests that go along with it.

We discuss this a little bit more in depth in our book...

Good luck with your project!

--
Cedric

Originally posted by Pavan Kumar:
Hello Cedric,

Thanks very much for looking into this thread.
I'd say I haven't made as much progress as I'd have liked, but I think I'm progressing a little slower but trying.

At this point,I'm of the opinion that good programmers write testable code, and I'm realizing that my test driving ability is mostly hampered by my code that's non testable. I'm still taking relatively larger steps when compared to the steps that have been shown in Kent's book. But this is going to take some time and more practice.

I've really done myself a favor by buying Lasse's book, Although I've read Unit Testing By Example the fastest, I think I'll be gaining much more to read it after I've read Lasse's book.

I'll be watching all the activity here for any inputs as well.

Thanks,
Pavan

[Ilja Preuss]

I'd argue, though, that practicing test-first will help you to learn writing testable code faster. That's because writing the test first makes testability a top priority instead of a hindsight.

[Walter Bernstein]

Originally posted by Ilja Preuss:
I'd argue, though, that practicing test-first will help you to learn writing testable code faster. That's because writing the test first makes testability a top priority instead of a hindsight.

Top priority is working code, not testing.

[Lasse Koskela]

Originally posted by Walter Bernstein:
Top priority is working code, not testing.

I'm sure Ilja didn't mean "top" literally.

Testing is waste. According to lean thinking, that is. Our customers wouldn't want to pay for us testing our code. They'd rather pay for us adding new features. However, we haven't yet figured out how to deliver those new features with high quality without testing so, in the meanwhile, testing is a temporarily necessary waste.

[Walter Bernstein]

Originally posted by Lasse Koskela:

However, we haven't yet figured out how to deliver those new features with high quality without testing so, in the meanwhile, testing is a temporarily necessary waste.

But it's not only necessary waste, it also sucks to the highest degree. I hope TestNG can ease my pain.

[Ilja Preuss]

Originally posted by Walter Bernstein:

Top priority is working code, not testing.

Without testing, I don't know whether my code is working - and keeps working. Ergo, to get working code, I need to test.

Also note that I wrote "*a* top priority", not "*the*".

[Ilja Preuss]

Originally posted by Lasse Koskela:

Testing is waste. According to lean thinking, that is.

I've heard that before, and it makes me wonder. Do managers at Toyota really consider the work associated with putting tight feedback loops into place being waste?

[Ilja Preuss]

Originally posted by Walter Bernstein:
But it's not only necessary waste, it also sucks to the highest degree.

Since I'm doing test driven development, I don't feel that it does any longer. In fact now I experience that I can increase the fun I have when programming by writing a test. Not because I use the right tool, but because I use a *process* that lets me benefit from a written test immediately.

[Daniel Trebbien]

I don't really think that some of you feel that testing is a waste. After all, how can a necessary thing that improves quality be wasteful?

I think the real frustration lies in the fact that programmers are asked to write tests for their own code. I know that when I write tests for my own code, I feel like I am writing everything twice or more and this is extremely frustrating.

[Lasse Koskela]

Originally posted by Daniel Trebbien:
I don't really think that some of you feel that testing is a waste. After all, how can a necessary thing that improves quality be wasteful?

I don't think testing is wasteful in the sense that we shouldn't be doing it.

I do think that testing is a "waste" in the way Lean Thinking defines waste. That is, it's an activity that does not directly add value into the product.

In the ideal world, a product would just be built. No contracts, no design documents, no design activities, no reviews, no testing, and so forth. Only people writing source code or a user manual. That would be a "lean" process--very little waste. However, that's not a feasible scenario. We do in fact need contracts, design, reviews, testing, and so forth. But we shouldn't forget that we do these things not because they add value to the customer (they don't) but because they help us add value to the customer.

[Walter Bernstein]

Without testing, I don't know whether my code is working - and keeps working. Ergo, to get working code, I need to test.
Sure, but it's not absolutly necessary to write a unit test.
Also note that I wrote "*a* top priority", not "*the*".
Sure, just tried to be a bit provocative.
I've heard that before, and it makes me wonder. Do managers at Toyota really consider the work associated with putting tight feedback loops into place being waste.
I don't know Toyota, but the mercedes guys I know, say it's waste - necessary waste.
Since I'm doing test driven development, I don't feel that it does any longer. In fact now I experience that I can increase the fun I have when programming by writing a test. Not because I use the right tool, but because I use a *process* that lets me benefit from a written test immediately.
That makes me really wonder. I'm a java web application developer and I've seen a lot of projects in the last 8 years. But I never met a 'test infected' person so far. What kind of applications do you develop? What implementation language do you use?

1) It's matter of common sense that we need testing.
2) But it's also matter of fact, that there is only very little automatic(unit) testing in real world web applications.
3) There is a lot of human testing here.
4) There must be a reason for this.

[Ilja Preuss]

Originally posted by Walter Bernstein:
What kind of applications do you develop? What implementation language do you use?

Since six years, I'm working on a platform for adhoc reporting with integrated GIS. It has both a Swing and a web front end, plus an API for thirdparty developers. See http://www.disy.net/disy_cadenza_pro0.html and http://www.disy.net/disy_cadenza_web_en.html for some screenshots.

It's implemented in Java, with some Groovy and the obvious JavaScript.

1) It's matter of common sense that we need testing.
2) But it's also matter of fact, that there is only very little automatic(unit) testing in real world web applications.
3) There is a lot of human testing here.
4) There must be a reason for this.

There certainly are reasons. I'd guess that most of them are cultural.

[Ilja Preuss]

Originally posted by Lasse Koskela:
In the ideal world, a product would just be built. No contracts, no design documents, no design activities, no reviews, no testing, and so forth. Only people writing source code or a user manual.[/QB]

Isn't writing the user manual waste, too? After all, the users don't exactly *want* to read a manual...

[Ilja Preuss]

Originally posted by Daniel Trebbien:

I think the real frustration lies in the fact that programmers are asked to write tests for their own code. I know that when I write tests for my own code, I feel like I am writing everything twice or more and this is extremely frustrating.

I take it that you test your code *after* you have written it? Because when I write my tests first, they help me a lot writing the production code, which is not at all frustrating, quite to the contrary.

Anyway, I find that, as a programmer I find that it is my responsibility to deliver code that is actually working. And as I don't know of a way to do that without testing the code, I find it quite reasonable to be asked to test the code I write. If I find that frustrating, it wouldn't feel professional to me to therefore drop the testing - instead I should find a way that is less frustrating (which could include finding an *alternative* to testing).

[Daniel Trebbien]

Hi Ilja,

I'll try your way (writing tests beforehand) next time. The only reservation that I have is, what happens if the API changes somewhat or design goals change? Then the contract changes and the tests have to be rewritten.

Do you encounter this often?

[Jeanne Boyarsky]

Originally posted by Daniel Trebbien:
The only reservation that I have is, what happens if the API changes somewhat or design goals change? Then the contract changes and the tests have to be rewritten.

The code needs to be rewritten too. What's wrong with them evolving together?

I like having the tests in place, even for API changes as I have regression for all the cases I thought of that were working. Otherwise, it's like starting over.

[Walter Bernstein]

Originally posted by Ilja Preuss:

Isn't writing the user manual waste, too? After all, the users don't exactly *want* to read a manual...

Check how Apple solves this problem. It's amazing.

[Walter Bernstein]

Originally posted by Ilja Preuss:

Since six years, I'm working on a platform for adhoc reporting with integrated GIS. It has both a Swing and a web front end, plus an API for thirdparty developers. See http://www.disy.net/disy_cadenza_pro0.html and http://www.disy.net/disy_cadenza_web_en.html for some screenshots.

Looks nice. What kind of tests do you write? Do you test everything? Can you give me some percentage numbers of the diffrent kinds of tests?

[Nicholas Jordan]

Originally posted by Walter Bernstein:

Check how Apple solves this problem. It's amazing.

Tell me more, this is crucial to something I am about to totally recode using the skills gained at Java Ranch and cannot unstick several "Silver Threads" ( thoughts - how the user thinks )

Trying to write tests for an operational environment of non-techie mentality is ultra-challenging: The threads and the data structures and the gui and all of that stuff is obvious for me .... but the mind of the customer is unfathomable to me because I am a techie and expect the button-pusher to,... do what ? I do not know, so I intend to post some Moose Manure in Meaningless Drivel over the holidays to match my last years effort about the mirror, thus the title I have decided will be Silver Threads.

Give me some links so I start at the correct place.

[Lasse Koskela]

Originally posted by Ilja Preuss:
Isn't writing the user manual waste, too? After all, the users don't exactly *want* to read a manual...

Yeah, you could see it as a waste except that many users are willing to pay a little extra just to get that manual whether or not they actually need it. Like an extended warranty period. In that sense, the manual could be seen as adding value to the customer.

Then again...

Originally posted by Walter Bernstein:
Check how Apple solves this problem. It's amazing.

I'm not sure what exactly Walter means by this but a printed manual is just one solution to the problem the customers are willing to pay for.

[Ilja Preuss]

Originally posted by Walter Bernstein:

Looks nice. What kind of tests do you write? Do you test everything? Can you give me some percentage numbers of the diffrent kinds of tests?

We currently write virtually exclusively JUnit (unit- and low-level integration-) tests. We experimented a bit with acceptance testing using FitNesse, with some success, but it's currently not our focus.

For some months now, in a subgroup of 4 developers, we try hard to test everything that could possibly break. It's working quite well.

Does that answer your question?
[ December 24, 2007: Message edited by: Ilja Preuss ]