Test Driven Development: By Example

I don't think you can do better than the original https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

To summarize:

1) Write a failing test 2) Make it pass as quickly as possible 3) Repeat and refactor as necessary

From memory, I think Kent Beck's Test Driven Development walks through some good examples. Probably a good book to refer to in testing training courses. http://www.amazon.co.uk/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530

http://www.amazon.com/dp/0321146530/?tag=stackoverfl08-20

If you've never done or are curious about TDD, this is a great book to carefully walk you through learning how and why to do it.

I believe that the framework is tested with itself. I'm sure I remember reading it in Kent Becks TDD book. Might be mistaken though.

Test Driven Development: By Example https://www.amazon.com/dp/0321146530/ref=cm_sw_r_cp_apa_i_qjeLCbZETRP32

Okay che si chiama "Learn Python The Hard Way", ma stampare i valori delle variabili a mano mi sembra un po' eccessivo, e va bene solo se devi fare uno scriptino al volo.

Ti hanno già suggerito cose valide.

Io aggiungo: impara a usare il modulo unittest, e magari procurati il libro di Kent Beck Test-Driven Development: By Example.

Avere un debugger a disposizione e saperlo usare è cosa buona e giusta, ma se ti prendi la briga di imparare a fare unit testing procedendo un passetto alla volta, riduci il tempo che passi a usarlo: proprio perché aggiungi/modifichi un minimo di funzionalità alla volta, ti è molto più facile renderti conto di dove hai fatto la cazzata senza far partire il debugger.

Non è sempre immediato rendere il codice testabile, ma è un ottimo esercizio che ti farà crescere un sacco. E alla fine ti troverai con in mano una batteria di test che lavorano per te, e un pezzo di codice che sei ragionevolmente sicuro farà quello che vuoi invece che quello che vorresti.

The best test framework is Junit -for unit tests, in my opinion. http://www.junit.org/ -for mocking objects, which you will need a lot, like to mock the database, mock services and other object in j2ee environment to be able to test in isolation .use http://www.jmock.org/ , http://code.google.com/p/mockito/, http://www.easymock.org/ -for acceptance and functional testing there is selenium http://seleniumhq.org/ this framework enables you to automate your tests. I Advice you to read this books about testing in general and testing in j2ee evironment in particular.

http://www.manning.com/rainsberger/ 
http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530
http://manning.com/massol/ 
http://manning.com/koskela/

I would suggest the following book: http://www.amazon.com/dp/0321146530/?tag=stackoverfl08-20 from Amazon
Beside the book recommendation, When you design your tests, you have a lot of work at the beginning, but at a point, for every new code, most of your test logic will already be on place.
I would also suggest to make sure you are focused on intrusion prevention as well (code that test for SQL injection, buffer ovf and so)
Another point to remember is that when the one who wrote the code is the one who wrote the tests, you might want someone else that will try to break it down... not for everything, but at least for part of it.

I had an epiphany about my problem. The simple answer is Test Driven Development.

I found myself developing by making a change to my application. Clean, Compile, and Deploy to Glassfish. I was finding this increasingly frustrating because of how slow that process is. In addition, I'm new to JavaEE development so I am working in small incremental steps.

The epiphany came when I saw and remembered reading about Test Driven Development from Kent Beck. I only made it to Chapter 6 but shelved it as other books took higher priority at the time. Now it's time to read it.

I highly recommend reading the book. Basically, the process is to build your unit tests first and use them to build the application.

Here is a link to the book I'm reading: http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=sr_1_1?ie=UTF8&qid=1324507172&sr=8-1

I was recently given this list of books by some very skilled engineers who I trust

1. [The Pragmatic Programmer](https://pragprog.com) 2. Martin Fowler's [Refactoring Book](https://martinfowler.com/books/refactoring.html) 3. Kent Beck's [Test Driven Development: By Example](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...) 4. [Thinking in Systems: A Primer](https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp...) 5. [Zen Mind, Beginner's Mind: Informal Talks on Zen Meditation and Practice](https://www.amazon.com/Zen-Mind-Beginners-Informal-Meditatio...) 6. [Pragmatic Thinking and Learning: Refactor Your Wetware](https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor....)

Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread:

Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

Vaughn Vernon, various: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2

Clean coder: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

Hitchhiker's Guide to Python: https://www.amazon.com/Art-Readable-Code-Practical-Technique...

John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!

Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

Dan Bader, Python Tricks: The Book: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...

Svilen Dobrev, various: http://www.svilendobrev.com/rabota/

I challenge your best book with the book of Kent Beck (founder of TDD) https://www.amazon.co.uk/Test-Driven-Development-Addison-Wes...

I think you have some misconceptions about TDD. For a good explanation and example of what it is and how to use it, I recommend reading Kent Beck's Test-Driven Development: By Example.

Here are a few further comments that may help you understand what TDD is and why some people swear by it:

"How do you combine test driven development with a design that has to change to reflect a growing understanding of the problem space?"

• TDD is a technique for exploring a problem space and creating and evolving a design that meets your needs. TDD is not something you do in addition to doing design; it is doing design.

"How do you make the TDD practice work for you instead of against you?"

• TDD is not "twice as much work" as not doing TDD. Yes, you'll write a lot of tests, but that doesn't really take much time, and the effort isn't wasted. You have to test your code somehow, right? Running automated tests are a lot quicker than manually testing whenever you change something.

• A lot of TDD tutorials present highly detailed tests of every method of every class. In real life, people don't do this. It is silly to write a test for every setter, every getter, and so on. The Beck book does a good job of showing how to use TDD to quickly design and implement something, slowing down to "baby steps" only when things get tricky. See How Deep Are Your Unit Tests for more on this point.

• TDD is not about regression testing. TDD is about thinking before you write code. But having regression tests is a nice side benefit. They don't guarantee that code will never break, but they help a lot.

• When you make changes that cause tests to break, that's not a bad thing; it's valuable feedback. Designs do change, and your tests aren't written in stone. If your design has changed so much that some tests are no longer valid, then just throw them away. Write the new tests you need to be confident about the new design.

Personally I think TDD is at best overkill and at worst an impediment to a the creative process of programming. Time that is spent laboriously writing unit tests for each as yet unwritten methods/classes would be better spent solving the original problem. That being said I am a big fan of unit tests and believe wholeheartedly in them. If I have a particularly complex or troublesome piece of code I'm more than happy to write 20 unit tests for a single method but generally AFTER I have solved the problem. TDD, just like every other programming paradigm, is no silver bullet. If is suits you use it if not keep looking.

But take my opinion with a grain of salt. A much more interesting one comes from Kent Beck and How deep are your unit tests?.

Kent Beck's book gives some examples in Java and some in Python (to be honest, Kent doesn't strike me as a superstar in either language, judging from the example code in this book... but he definitely comes across as a superstar in TDD &c -- as well he should, given he's basically invented it as well as extreme programming, see his wikipedia entry).

I'd honestly recommend looking at Martin Fowlers Patterns of Enterprise Application Architecture. It discusses a lot of ways to make your application more organized and maintainable. In addition, I would recommend using unit testing to give you better comprehension of your code. Kent Beck's book on Test Driven Development is a great resource for learning how to address change to your code through unit tests.

I think that you are going in the right way. But I will send some suggestions;

• Move the self.testdata.close() from setUp() to the tearDown() function.
• Surround the others open/close with try/finally blocks. So, if a file didn't open with success it will be closed.

    try:
        file.open()
    finally:
        file.close()

• Organize better your test folders. I suggest you to create a folder named _tests and inside this folder you should put the tests module (at your case you only have one module). Then, for each module create a folder with the name of the module and puts the files used by the tests of a module inside this folder.

To know more about TDD and tests you should read the book Test Driven Development: By Example

I'm not a purist in this matter (TDD involves more than just writing the tests first, it's also about initially writing very minimal, "hard coded" tests and refactoring them a lot -- see The Book by The Master himself).

I tend to test-first when I'm doing incremental development to add a feature to an existing module, and I insist on test-first when the incremental development I'm doing is to fix a bug (in the latter case I absolutely want a unit-test AND an integration-test that both reproduce the bug, before I fix the code that caused the bug).

I tend to be laxer when I'm doing "greenfield" development, especially if that's of an exploratory, "let's see what we can do here that's useful", nature -- which does happen, e.g. in data mining and the like -- you have a somewhat vague idea that there might be a useful signal buried in the data, some hypothesis about its possible nature and smart ways to [maybe] extract it -- the tests won't help until the exploration has progressed quite a bit.

And, once I start feeling happy with what I've got, and thus start writing tests, I don't necessarily have to redo the "exploratory" code from scratch (as I keep it clean and usable as I go, not too hard to do especially in Python, but also in R and other flexible languages).

I read many tutorials and several books on TDD but never quite got it until I read Kent Beck's Test Driven Development By Example[1]. I also highly recommend his Screencast series on pragprog.com[2] which gives you a good flavour of the workflow he uses with TDD.

Edit: For those that don't know Kent Beck is basically the godfather of TDD.

[1] http://www.amazon.com/Test-Driven-Development-By-Example/dp/...

[2] http://pragprog.com/screencasts/v-kbtdd/test-driven-developm...

:) Kent Beck doesn't promote it anymore, but in the early 2000's that was what was understood.

From "Test Driven Development" by Kent Beck, published 2002: http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0...

Here are some excerpts:

"What test do we need first? Looking at the list, the first test looks complicated. Start small or not at all. Multiplication, how hard could that be? We'll work on that one first."

The examples like this that were provided were of trivial methods. Trivial can be subjective, but, to me, methods whose bodies are almost always 2-5 lines long, not counting calls to other trivial methods, which may account for maybe another 2-3 additional lines, are basically trivial. It's one thing when you really don't need that much code, but it's another when you have classes upon classes upon classes upon classes, etc. to do something that could be OO and be in two classes with 1/2 as many lines and still be clear.

"Do these steps seem small to you? Remember TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps. Would I code day-to-day with steps this small? No. But when things get the least bit wierd, I'm glad I can."

This is what Kent meant, but few of us picked up on it, per the first comment to his answer in your example from S.O. and per my experience.

I'm not blaming Kent, Ron, etc. or even saying that they are or were wrong. But, the commonly understood epitome of TDD used to be 100% test coverage and methods for just about everything. Those in the know said more like 60% was better overall but that was not really "true TDD". The implication of 100% "trivial" methods is more overhead for method calls (minor cost, depending, but can be cumulative, increase/decrease call stack size more quickly, which is inefficient), a large number of entry points (more stuff can be null/nil, cause NPE's or need checks if you don't know what is going to call it later, though that can be mitigated somewhat), and just generally too many LOC.