What is Digg?Sponsored by Double Your Dating
Scary Quiz - Do you have what it takes to attract women? view!
doubleyourdating.com - Think you know a thing or two about meeting women? Take this quiz and find out...
58 Comments
- TigerX, on 10/12/2007, -0/+13Non-Programers, see here:
http://en.wikipedia.org/wiki/Unit_test - MikeWeller, on 10/12/2007, -0/+7That really isn't the right way to go about things. Code will always require changes and modifications. If you need to add functionality you will often end up refactoring existing code to reduce code repetition, and clean stuff up as you go.
If you have written good unit tests, you can make all these modifications, and be sure you haven't broken anything: just run your tests and if they pass, everything is OK.
Unit tests are also a great design tool. By writing the tests *before* you've written the classes/functions, you can play around with method names, class names, and how data is input/output from that class. It's really a great way to design stuff. - Run4yourlives, on 10/12/2007, -0/+6remind where you work again... I want to avoid your software at all costs.
- exaviger, on 10/12/2007, -0/+6good philosophy,
It doesnt hold to well when someone else has to work on your code and is not 100% sure what it does or if adding/editing/removing something is going to effect it negativley or not. Your unit tests will!
It is also very handy to run a set of unit tests when deploying your application on a different machine (as mentioned in the article) going through every step of the application to check that it is working correctly is impossible! - aguita, on 10/12/2007, -0/+6Design your tests first is a mantra that all good developers should have. Test what you can -- gui tests are much more difficult, but still can be done.
- MikeWeller, on 10/12/2007, -0/+5I have to disagree... I think writing unit tests early on will *save* time on debugging, refactoring, and making sure stuff works. I've made another post in this page talking about how unit tests also help in the design process - you can figure out what your class methods will be, and how classes/objects interact by writing the test code. Without unit tests you'll often realise late on in the development process that you need to change the way a class behaves because you didn't predict a certain kind of usage.
And with a good unit testing framework it really doesn't take that long to write tests... - Run4yourlives, on 10/12/2007, -0/+5"My developer philosophy is to write it correctly the first time without errors."
Which assumes that your requirements are solid and non-variable for the lifetime of the software.
Anyone who's actually written any working software anywhere will tell you that the likely-hood of this happening is precisely 0, which is why your philosophy is fundamentally flawed. - Beanlover, on 10/12/2007, -1/+6"Unit testing" on the cheap:
If it compiles...SHIP IT! - bpapa, on 10/12/2007, -0/+4Unit testing is awesome for any sort of refactoring that you need to do down the line. Change a number of source files? Have confidence with Unit Test to verify that your refactoring still works.
- robbyjo, on 10/12/2007, -1/+5I agree that good programmers must unit test. However, how can you suppose to unit test visual / GUI elements?
- krynsky, on 10/12/2007, -0/+4Personally I would have opted for the articles title as your digg headline "Unit Testers Get More Chicks". That's a great line...
- OneZeroZeroOne, on 10/12/2007, -0/+3This assumes that you were the one to write the code in the first place.
I've only ever had one job where this was the case.
More than likely you will inherit a legacy system and budget/time constraints will be obstacles.
Often when you need to dig into a piece of code, you don't have time or authorization to rewrite/refactor it. Instead you just look at how the other people did things and follow the leader, feeling slightly dirty afterwards. - robfeinstein, on 10/12/2007, -0/+3Iterative unit testing by developers, combined with end-to-end QA testing planned to last as long as the development time for each of the units, is the best way to go.
- Valdar, on 10/12/2007, -0/+3I own a multi-million dollar manufacturing company that has nothing to do with software, but I've written our software that controls everything: Payroll, piecework, A/R, A/P, CRM, shipping, inventory, lead tracking, document imaging, etc. It helps us keep an edge on our competitors because we employee about 1/3rd of the staff off similar sized companies in our field.
I design the software, write the units tests and then give that to my developers I've hired in Romania and India. They can't commit the code until it passes all the unit tests. This works great because they can't mess it up, it either passes or it doesn't. I get two developers at half the cost of one full time developer and I have hundreds of unit tests to ensure that everything works properly. Then I have my UI guy, also in Romania, wire up all the code for the UI he has been designing the entire time they have been making the unit tests pass.
I still do code audits and make changes to make code cleaner, then just run my unit tests to make sure my changes didn't break anything. But I only spend 3-4 hours per week actually programming.
My company succeeds by automated testing & deployment (and nightly backups). I can't recommend it enough. - BigDaddy71, on 10/12/2007, -0/+3Developers need to stop acting like wusses and push back on testing requirements. I believe in unit testing, and it SAVES YOU TIME when you create tests at the same time you create the code. Shoehorning unit tests into an existing app is a nightmare (went through that at my previous employer) but the biggest problem is whiny developers who don't see the benefit in writing tests for the code they write. Bigger than the whiny developers who insist that unit tests save time. :)
- WilliamTanksley, on 10/12/2007, -0/+3Well, I'm not sure how you're reading "unit test"; I think most people here, including the author of the article, are using it in a much more general sense than you are. Your practice of writing test functions inside each object is not unknown in the unit testing world; it's generally discouraged for several reasons:
1. It mixes up the class's interface (the class no longer can be said to Do One Thing);
2. It allows the testing code to play with class internals, making the test code a bad example of how to use the class;
3. It makes it too easy to ship extra code to the customer, possibly including extra behavior which is not useful to the customer.
As a final negative side effect, if you're not using a testing framework, you have to "fiddle" with the code in order to run the test, which means that the test won't always get run. And if you are using a testing framework, it won't support what you're describing anyhow. - muddo, on 10/12/2007, -0/+3@asteron
How can you verify that a system works correctly without testing it? - calhoun, on 10/12/2007, -0/+2asteron ====
My developer philosophy is to write it correctly the first time without errors. Once you start doing this it really cuts down on debug time and testing
===========
That's some excellent circular reasoning there. Don't make errors so you don't need to test for errors! No kidding. - Run4yourlives, on 10/12/2007, -0/+2unfortunately very true for most shops!
- JaredRR, on 10/12/2007, -1/+3Google these.
HTMLUnit
HtmlUnit
JWebUnit
Abbott
Selenium
There are ~tons~ of GUI testing frameworks. They tend to be more integration tests than unit tests. If you follow a good MVC design pattern, it becomes possible to cleanly test your system. - captaindan, on 10/12/2007, -0/+2More chicks than what? We're talking about programmers here.
- krynsky, on 10/12/2007, -0/+2Well that's a good point...lets say we limited the scope to who gets more chicks within a company tech dept. So that limits the field to IT, Development, QA, Project / Program Management..and possibly other areas depending on the company. In that scenario I would have to say that the project managers get more chicks than unit testers mainly because they get to interact with the business side (which includes the hot marketing chicks) and aren't as isolated as the rest of tech. Of course that comes from a guy who is a project manager, who with a little schmoozing (wink wink) might just get that marketing project done on time :)
- burke, on 10/12/2007, -0/+1this annoys you why?
- AxelTorvlads, on 10/12/2007, -0/+1What are the downsides of unit testing? Seriously?
- alex007, on 10/12/2007, -0/+1iDad: unfortunately robot breaks down when it comes to .Net. Especially when you start talking about panels and custom controls
- BigDaddy71, on 10/12/2007, -0/+1There are multiple types of testing, so don't get confused:
unit testing - done by the people who write the code to make sure their discrete code works the way it's supposed to in isolation
integration testing - done to make sure that you didn't break the application with your changes
requirements testing - making sure the final product does what it is supposed to
If you miss out on any of this, you're screwed. - TopBanana, on 10/12/2007, -0/+1Unit testing works better for some sorts of things than others. In the last couple of days I've knocked up a text rendering template thingy, which generates compiled .Net assemblies from templates. Works very well and all the work was test-driven. Today I've had to do some UI stuff, and TDD just doesn't help.
- Run4yourlives, on 10/12/2007, -0/+1At that point though you have the ever present conundrum: Is this client worth it?
IMHO, way too many companies are way too eager to answer "yes" to this question without assessing the long term effects, which can be disastrous. As an example, take your fictitious demanding client who doesn't "realize" the effects of scrapping unit tests. When the software is delivered as buggy and incomplete, that client will pass the word that your organization are piss poor developers, regardless if this assertion is correct. How does that help you at all?
From my experience, these clients should be "fired" if they cannot be educated. Contrary to popular belief, there are plenty of customers who "get it". They are a pleasure to work with and allow you to take great pride in delivering quality software to them. It's win-win all around, albeit sometimes with less of an immediate payoff. - inactive, on 10/12/2007, -1/+2I work on a voicemail system for telecos. Nobody here gives a grap about testing even though we really need it:
Recently, a co-worker wrote some code that threw our server into an infinite loop after EVERY call terminated. He delivered the code to the customer without ever testing it. Course I'M the one they call when his stuff breaks.
Next release is months behind schedule because project management never actually got the requirements we need. In a team meeting, the VP of engineering told us "It's OK if development is a little bit late because there's 30 days allocated for testing. We can just eat into that." 30 days isnt nearly enough time to test, and eating into other peoples' schedules is what got us into this mess in the first place. - foobario, on 10/12/2007, -0/+1now I'm trying to figure out which of my co-workers you are.
- WhiskerTheMad, on 10/12/2007, -1/+2...and I don't carry car insurance. I just never get into accidents.
Moron. - waynechng, on 10/12/2007, -0/+1I've worked on both sides, development and test, so I see both points of view. However, I believe in building the best product that I can so I believe in testing everything. Many developers believe that their code works 100% of the time in their small area of the universe. Great, except that it means nothing if it doesn't play with anything else in the universe..
I currently work as a tester, white- and black-box. I've also built up a reputation for approving products that rarely have fail in the field. Hence, I bitchsmack our developers to the back of the line if I unit test their stuff and it breaks, and management supports me 100%. - Valdar, on 10/12/2007, -0/+1I use NUnit (I know, .Net booo, it sucks, etc.) for my testing and I can do much more than component level testing. I do integration testing across components. With mock objects you can even do testing that involves utilizing outside sources (web services, credit card processors, document scanning, etc).
- JaredRR, on 10/12/2007, -0/+1JUnit (and all the XUnit testing frameworks) can be used for much more than a traditional "unit test". (fair warning, this is my blog entry on the topic).... JUnit is not a Unit Testing framework -> http://www.jaredrichardson.net/blog/2005/07/24#junit-isnt-unit
- Run4yourlives, on 10/12/2007, -0/+1Read here for my take. http://run4yourlives.com/archives/2006/04/17/agile-development-with-rails-workshop/
- ezran, on 10/12/2007, -0/+0For web testing, you can use TestGen4Web [ http://developer.spikesource.com/projects/testgen4web ]
- iDad, on 10/12/2007, -0/+0For application GUI testing, I have been using IBM's Rational Robot (http://www-306.ibm.com/software/awdtools/tester/robot/sysreq/index.html). This is a do-what-I-do tool that lets you record sessions and string them together. You can also compare values (e.g. in a calculation) to a baseline. When you add new functionality or fix a bug, you add a new test. Then run the entire set of tests before each delivery for a thorough regression test. Results: very happy customers.
- roadkill001, on 10/12/2007, -0/+0Ruling out how to unit test Web apps for the moment. I think unit testing works better in a team development. I think it can save time for code that is changed frequently that needs regression testing to make sure that the new feature or whatever was added didn't break stuff that worked before. Writing good unit tests is a skill and can be time consuming depending on the app. Writing the unit tests before coding anything is not always possible. I'm trying to be as generic as possible language wise, but as with anything in life unit tests have things going for them and things against them. Should they be done probably... but in the end writing unit tests is usualy tedious work that rates right up there with documentation.
- st00p1d, on 10/12/2007, -0/+0 I totally agree. But it's easy to do unit testing when you start it from the beginning. How do you do it when you're adding enhancements/making bug fixes to 50,000-100,000 lines of legacy code?
I guess what I'm saying is that there are ways of testing while coding which will have simmilar results to unit testing but don't require bootstrapping and entire testing framework on legacy code.
As usual, the real world creeps in... - d03boy, on 10/12/2007, -1/+1If you're using something such as Swing then there really shouldn't be a need to test that portion. If you wrote the code correctly it should look fine. So unit test the code instead.
- digitalsin, on 10/12/2007, -4/+4indeed!
- zirtbow, on 10/12/2007, -0/+0Where I work we don't use unit tests... extra time to write the test fixtures was deemed to have 'no value added'. I don't mind as much though... saves a little (very little) on dev time.
- alienz, on 10/12/2007, -0/+0Know why I can't stand Unit Tests at this point. We hired a group of programmers who use Testing all the time for a project. It's not some crazy eCommerce application, just a CMS I suppose. They use the XP (eXtreme Programming) method to write code just so it passes the tests they write.
What did we end up with? An app that passes a bunch of tests, doesn't meet requirements, missed deadlines, code is a mess all because they spent so much time on testing.
Proof that testing does not produce good code and great projects automatically.
No amount of process can account for poor planning and thinking. Instead of sitting down and thinking out everything they just jumped in and started coding because that's what XP lets you do. Code without fear.
Great for University, business world? Not so much. - acrylic, on 10/12/2007, -0/+0The concept could be applied to any agile language.
- njleaton, on 10/12/2007, -0/+0One issue with unit tests is the limited number of paths through the software the tests test.
Secondly, I'm not convinced that writing the test first, is the best way of writing code.
Taking each of these points in turn. You can address part of the limit number of paths by combining a code coverage tool with your unit tests. If you don't get code coverage, you can add more tests. However, what you really need is something that tests all the time.
Secondly, writing the test first focuses on a particular case, not on producing a good abstraction or good code. If you are not careful, the code is produced to meet a particular test case, not the set of test cases, or even the set of possible data.
I've worked for a long time with Eiffel, and it has the interesting feature of design by contract. This combined with unit tests takes things to the next level. A lot of people who comment on DBC, have never used DBC in practice.
First, you change the way you program. It isn't write unit test first, it is contract first. Then write code / unit test. The change of emphasis is produce code that covers all cases. All cases are defined by the contract. Now it becomes clearer what the test cases are. You need to exercise the cases defined by the contract. Whether you right the tests, or the code first doesn't matter.
Importantly, if you run the code with assertion checking on, you are testing the contracts as you go. Instead of testing just specific cases, you get universal testing. It is far more powerful.
There are some other alternatives that I can see coming in the future. FxCop and other static code analyzers are getting more sophisticated. Software such as the proposed NStatic are also interesting. Combining these with DBC would make something really powerful. I can also see the day when run time analysis during testing feeds back into the static analysis - Valdar, on 10/12/2007, -0/+0I've done this with legacy projects. You don't have to have a unit test for all your legacy code, just for the NEW code you write.
If there a was a bug in the legacy code we would create a new test for that bug only, not for the entire application. Slowly, over time, you build into hundreds of unit tests which give you much more confidence when making changes. - jfritz828, on 10/12/2007, -0/+0Scott Hanselman (http://www.hanselman.com/blog/) is a huge believer in Watir (http://wtr.rubyforge.org/) for web UI testing.
I haven't personally tried it, but he has a few podcasts regarding unit tests and Agile development techniques where he raves about the tool. - antdude, on 10/12/2007, -1/+1Why would anyone want cute little birds? :P
- Valdar, on 10/12/2007, -0/+0Then they didn't do it right. You don't test everything your app does, just the important stuff. When you hit a bug, write a new test to test that bug.
Testing for things like CRUD is kind of useless because a problem like that will be exposed by your other unit/integration tests. Testing to make sure that when someone makes a change in your CMS that an audit trail is properly created IS something you should test for. - EiderDuck, on 10/12/2007, -0/+0I once joined a 10-person team as the technical lead where the ongoing philosophy was that anything that compiled without error was, by definition, correct. I went insane in 6 months trying to convice people that just because their code didn't break the nightly build didn't mean it was fine.
-
Show 51 - 58 of 58 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is