Good books on TDD and UI Design?

[Tom]

I've been meaning to "expand my horizons" as it were for a while now. Want to finally understand this "Test Driven Development" thing better. And improve my User Interface Design skills (they are QUITE lacking at the moment).

If you guys have any good tips, resources, books, whathaveyou, please share

[Mr. Analog]

Sh-bam! -> Test Driven Development: By Example

Concepts/Tools that are going to be key:
-Automating Tests
-Code Coverage Tools
-Complexity Analysis
-Inversion of Control
-Refactoring

IoC can be a lightbulb moment for many programmers, and it usually doesn't become apparent until you start automating tests. The other thing you have to lose is fear of changing code that "works", if it's a pain in the ass to test and/or it's really monolithic and returning poor complexity numbers it usually means the code is going to be a bitch to maintain or extremely difficult to change. TDD can also expose other things you don't expect like threading/concurrency issues, overly tight coupling and duplication of work. It also comes in handy when working on bugs, create a test that replicates the bug condition and then fix it, chances are you'll increase coverage with the test/fix anyway, plus it's a great way to add unit tests to existing code.

Find out what tools are available out there, try a few to get a feel for what each one offers and then pick the best one. Don't worry about differences in coverage reports, just pick whatever tool has the most automation and never ever worry about trying to get 100% coverage.

The main thing is to write your tests before you write the code because honestly if you aren't ready to write the test you are for sure not ready to write the code.

[Thorin]

My suggestion is to work on a pet project, greenfield (meaning starting new on it), with someone who already understands and practices test-driven development.  Have them show you in real time how they write a few tests and code to pass those tests, then try it for a bit, then ask them to show you how to make mock objects to use in Inversion-of-Control scenarios, then try that for a bit.

Good tools make this very easy, bad tools will make this hard.  But no matter what, just remember that you want to write the test first, run it and have it fail, write the actual code, run the test again and have it pass:

1. write test (stub methods in code-under-test if required)
2. run test and watch it fail
3. write code in code-under-test so it'll pass
4. run test again and watch it pass
5. make sure code-under-test is self-contained, not calling other DLLs / assemblies / external things

Small methods make this easier.  Using mock objects makes this easier.  Making sure that your tests only test the immediate code, not crossing boundaries like going to the file system to read files or going to the database to read data, makes this easier.

If you were to write code to practice TDD, what language would you want to use?

[Mr. Analog]

Yeah the tools and the language generally go hand in hand, from personal experience  Java has more advanced tools but .NET is catching up.

You might also want to start looking into using Continuous Integration (CI) along side unit testing, where builds are triggered on checkin so you always have an idea if something is going to be a breaking change.

[Tom]

My suggestion is to work on a pet project, greenfield (meaning starting new on it), with someone who already understands and practices test-driven development.  Have them show you in real time how they write a few tests and code to pass those tests, then try it for a bit, then ask them to show you how to make mock objects to use in Inversion-of-Control scenarios, then try that for a bit.

Good tools make this very easy, bad tools will make this hard.  But no matter what, just remember that you want to write the test first, run it and have it fail, write the actual code, run the test again and have it pass:

1. write test (stub methods in code-under-test if required)
2. run test and watch it fail
3. write code in code-under-test so it'll pass
4. run test again and watch it pass
5. make sure code-under-test is self-contained, not calling other DLLs / assemblies / external things

Small methods make this easier.  Using mock objects makes this easier.  Making sure that your tests only test the immediate code, not crossing boundaries like going to the file system to read files or going to the database to read data, makes this easier.

If you were to write code to practice TDD, what language would you want to use?

Ugh. somehow the forums (or firefox) lost my first reply...

Anyhow, my first two choices would be Perl and C++, but I'll likely (eventually) be doing some with PHP (for the new job). And may do some with Java (for android) in the future.

The fun part is some/one of the things I'm working on doesn't really have anything directly testable. It's a horrible interdependent mass of C and Java. The C stuff mostly has its own test cases (which I had nothing to do with), and the code I've been working on is pure glue code. Makes the framework written in C talk to Android's Java based platform. Means a lot of C and Java glue code. It's really fun let me tell you.

[Mr. Analog]

Using TDD on glue code is actually a really good start because there are supposed to be known behaviours from both sides. I think I mentioned before that the worst part with TDD is getting started, at first it seems like a mountain but if you start with your own new code and branch out over time you'll chip away at it bit by bit and eventually have coverage.

Have you thought about rails at all? I have a couple friends in the YEGRB I could connect you with, they also happen to be part of the Agile group here in Edmonton.

[Tom]

Using TDD on glue code is actually a really good start because there are supposed to be known behaviours from both sides. I think I mentioned before that the worst part with TDD is getting started, at first it seems like a mountain but if you start with your own new code and branch out over time you'll chip away at it bit by bit and eventually have coverage.

Have you thought about rails at all? I have a couple friends in the YEGRB I could connect you with, they also happen to be part of the Agile group here in Edmonton.

Rails is Ruby is it not?

I'm not entirely sure how testing would work on code that runs on a phone. Especially on both the java and C sides. Main events on the java side come directly from Dalvik, C stuff comes from user code (running in a separate thread).. And then the glue coed does tricksy things to translate back and forth.

[Mr. Analog]

Using TDD on glue code is actually a really good start because there are supposed to be known behaviours from both sides. I think I mentioned before that the worst part with TDD is getting started, at first it seems like a mountain but if you start with your own new code and branch out over time you'll chip away at it bit by bit and eventually have coverage.

Have you thought about rails at all? I have a couple friends in the YEGRB I could connect you with, they also happen to be part of the Agile group here in Edmonton.

Rails is Ruby is it not?

I'm not entirely sure how testing would work on code that runs on a phone. Especially on both the java and C sides. Main events on the java side come directly from Dalvik, C stuff comes from user code (running in a separate thread).. And then the glue coed does tricksy things to translate back and forth.

Yep, Ruby on Rails, lots of tools out there from what I gather.

Aha, well the idea is that you set tests up that behave like the phone but you run them in your own little pretend world. In fact there are several tools out there for Mocking (like http://www.jmock.org/ ).

Man maybe we should do some pair programming so I can sort of show you what I'm talking about, when you see what I'm talking about it makes a whole lot more sense.

[Tom]

Using TDD on glue code is actually a really good start because there are supposed to be known behaviours from both sides. I think I mentioned before that the worst part with TDD is getting started, at first it seems like a mountain but if you start with your own new code and branch out over time you'll chip away at it bit by bit and eventually have coverage.

Have you thought about rails at all? I have a couple friends in the YEGRB I could connect you with, they also happen to be part of the Agile group here in Edmonton.

Rails is Ruby is it not?

I'm not entirely sure how testing would work on code that runs on a phone. Especially on both the java and C sides. Main events on the java side come directly from Dalvik, C stuff comes from user code (running in a separate thread).. And then the glue coed does tricksy things to translate back and forth.

Yep, Ruby on Rails, lots of tools out there from what I gather.

Aha, well the idea is that you set tests up that behave like the phone but you run them in your own little pretend world. In fact there are several tools out there for Mocking (like http://www.jmock.org/ ).

Man maybe we should do some pair programming so I can sort of show you what I'm talking about, when you see what I'm talking about it makes a whole lot more sense.

Yeah, I'll have to look into that now. I just learned that my new project at work is a new android app. It'll be (imo) significantly easier to test.

Infact today I get to start looking up how to use the Android camera APIs and well as data management stuff (when to, and not to use data, and how much, etc).

[Mr. Analog]

Sounds cool, well if you ever want to pair up let me know we can hook up screen sharing on Skype or something and I can give you an intro to all this crazy.

[Tom]

Sounds cool, well if you ever want to pair up let me know we can hook up screen sharing on Skype or something and I can give you an intro to all this crazy.

Would be cool. I tend to learn best through seeing, and doing.

I actually have some time free today, or tomorrow after my dr. appointment, or really just about any other time. When ever is good for you (at least till I get some solid tasks to start on, right now we're/I'm in planning and research phase, and this sort of thing qualifies as research).

[Mr. Analog]

I'll see if I can prep some stuff first. It will just be concepts and I'll have to show you in .NET (my Java development VirtualBox image seems to be corrupted, I think I have a backup on DVD somewhere...)

The main thing are the concepts though.

[Thorin]

I tend to learn best through seeing, and doing.

Yeah, you're not unique in that aspect.  Which is why I suggested hooking up with someone who knows it already

Hmm, Android is all Java-based, right?

[Mr. Analog]

A custom Java port, yes.

[Tom]

I tend to learn best through seeing, and doing.

Yeah, you're not unique in that aspect.  Which is why I suggested hooking up with someone who knows it already

Hmm, Android is all Java-based, right?

Uses the Java programming language, and supports a rather large cross section of the standard library. But the VM itself (called Dalvik) is totally custom.