next »

[kurdt]

How many here actually writes unit tests? I recently started a new project where I tried to start by writing tests first and then the code. And after few weeks I can tell you that writing apps by going in tests first is the only right way. The complexity that your average program has when it has to deal with user input is just overwhelming to test if you are doing it manually. I know I might be preaching to the converted already but I just read this developer survey that highlighted that majority of programmers don't do unit testing. I avoided it for the longest time because it seemed so slow and complex. And it is if you try to write tests after you have written the code itself. Correct way (at least for me) is to design the function in the unit test and then write it so that it passes the test. The best part is that you know exactly when you are done, the moment the test passes. Of course you still might want to tweak error handling etc. but for that I suggest you just catch everything and create a lib that alerts you when something goes wrong. Then you just write a test that replicates the problem and fix the code so that the test passes.

Next step for me is to dive into behavior driven developing. That's just basically describing how the app itself works as a test and then writing individual unit tests and then the functions that make it happen. Cucumber is a great example of this, you can check it out at http://cukes.info/. Too bad it's more or less Ruby focused but there's wrappers for many other languages and other languages might have even language specific alternatives.

[vsloathe]

You're talking about test-driven development. We used to do that where I work. TDD is a good way of doing things, but it's not the only way, and it's not the best way for a lot of projects. Now we generally regression test with tools like jmeter.

[isthisthingon]

Cucumber is awesome from what I've seen of it (webinar and demos at work) and I believe it's behavior driven development - not TDD.  These are easily confused though.  Another nice dose of confusion is when people talk about acceptance driven development (Agile enthusiasts experiencing Jira for the first time are quite fond of this).  TDD is a really great thing and after years of writing unit tests for everything I can't imagine living without it, or rather, without good automated unit tests.  TDD is not really necessary after a while when you develop testable code, though it's more satisfying imo.  These days it's Agile, continuous integration and refactoring with success being measured in functionality and quality not milestones and Gantt charts.  Velocity and story points not WAG dates and mythical man hours.

Yet when absolutely everything must begin with a failing test, then get coded, then pass the test, I can't help but ponder the obvious:

Doesn't anyone friggin prototype anymore??

 

But seriously, I'm a coolaid drinking unit test believer, especially working with larger silicon clouds.  Cross-team impact potential of releasing APIs/modules without tests?     Great book on the subject: Working Effectively with Legacy Code by Michael Feathers.  He defines legacy code as code without tests, since without them you really don't know if the code is getting better or worse with enhancements and refactoring - especially after some time has passed and you don't remember it as well, or of course if the code isn't yours to begin with.

[perkiset]

Testing? 

[richie11brandon]

Unit testing primary goal requires drivers and stubs to be written.

[isthisthingon]

 

[perkiset]

[isthisthingon]

    

[nop_90]

Depends what you are doing.
On paper a good idea.
If you can figure out a test framework to test a plugin .....