My Unit Testing e-book is published!
-
Leave the thunder where it belongs. If you pulled a stunt like that on me, I'd kick your arse.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Use a number with a 555 area code and they'll think you're a movie star.
I wanna be a eunuchs developer! Pass me a bread knife!
-
[toot toot] Woohoo! If you want a refreshing view of unit testing (would you expect anything else, hahaha) download Unit Testing Succinctly[^]. [/toot toot] Incidentally, I quite enjoyed working with SyncFusion - they paid decently for the book, did some great editing, and the entire experience was very pleasant. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogSounds interesting, but I don't want to give the SyncFusion sales people my contact info, especially since I don't have any purchasing authority. Perhaps it will be available from some other source soon.
-
Sounds interesting, but I don't want to give the SyncFusion sales people my contact info, especially since I don't have any purchasing authority. Perhaps it will be available from some other source soon.
RefugeeFromSlashDot wrote:
but I don't want to give the SyncFusion sales people my contact info
Well, it accepts fake phone and email as well. ;) Marc
-
[toot toot] Woohoo! If you want a refreshing view of unit testing (would you expect anything else, hahaha) download Unit Testing Succinctly[^]. [/toot toot] Incidentally, I quite enjoyed working with SyncFusion - they paid decently for the book, did some great editing, and the entire experience was very pleasant. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogHi Marc I read your post and decided to down load your book. I've given it a good read now and thought it was very informative. I've recently been increasing my use of unit testing and you gave me some good information and some new ideas to try. I particularly liked the comparison between NUnit and the Visual Studio testing framework. I have one question about bug fixing. I get the part about writing a negative test to recreate the bug and then a positive test to test what should happen. Once you've fixed the bug do you keep the negative test or do you delete it and just keep the positive one. Thanks Stephen Well that's my first post done then!!
-
Hi Marc I read your post and decided to down load your book. I've given it a good read now and thought it was very informative. I've recently been increasing my use of unit testing and you gave me some good information and some new ideas to try. I particularly liked the comparison between NUnit and the Visual Studio testing framework. I have one question about bug fixing. I get the part about writing a negative test to recreate the bug and then a positive test to test what should happen. Once you've fixed the bug do you keep the negative test or do you delete it and just keep the positive one. Thanks Stephen Well that's my first post done then!!
Hi Stephen, Wow, thanks for the great feedback! As to your question, I'll quote this from StackOverflow: Positive Testing - testing the system by giving the valid data. Negative Testing - testing the system by giving the Invalid data. For Example, an application contains a textbox and as per the user's Requirements the textbox should accept only Strings.By providing only String as input data to the textbox & to check whether its working properly or not means it is Positive Testing. If giving the input other than String means it is negative Testing.. Negative testing improves the testing coverage of your application. Using the negative and positive testing approaches together allows you to test your applications with any possible input data (both valid and invalid) and can help you make your application more stable and reliable. So, there's two possibilities: One (code isn't buggy, it just doesn't handle bad inputs correctly): what you want the negative test to ultimately verify is that the code handles in some expected way (an exception, an error code return, a log entry, etc.) the conditions that result in a failure. So you would still keep the negative test after possibly improving the code's error handling, and only change the negative test, adding something like "ExpectedException" or some such verification that the error was handled. Two (code has a bug): The code simply has a bug, and the "negative test" re-creates the issue. Once the bug is fixed, the "negative test" actually becomes a "positive test", verifying that the code now handles the inputs correctly. In this case, you wouldn't need to write a positive test. Does that help clarify things? Marc
-
Hi Stephen, Wow, thanks for the great feedback! As to your question, I'll quote this from StackOverflow: Positive Testing - testing the system by giving the valid data. Negative Testing - testing the system by giving the Invalid data. For Example, an application contains a textbox and as per the user's Requirements the textbox should accept only Strings.By providing only String as input data to the textbox & to check whether its working properly or not means it is Positive Testing. If giving the input other than String means it is negative Testing.. Negative testing improves the testing coverage of your application. Using the negative and positive testing approaches together allows you to test your applications with any possible input data (both valid and invalid) and can help you make your application more stable and reliable. So, there's two possibilities: One (code isn't buggy, it just doesn't handle bad inputs correctly): what you want the negative test to ultimately verify is that the code handles in some expected way (an exception, an error code return, a log entry, etc.) the conditions that result in a failure. So you would still keep the negative test after possibly improving the code's error handling, and only change the negative test, adding something like "ExpectedException" or some such verification that the error was handled. Two (code has a bug): The code simply has a bug, and the "negative test" re-creates the issue. Once the bug is fixed, the "negative test" actually becomes a "positive test", verifying that the code now handles the inputs correctly. In this case, you wouldn't need to write a positive test. Does that help clarify things? Marc
Hi Marc Thanks for the reply. I guess my question is more about the process of bug fixing. This is how I think it goes. 1. A bug is reported. 2. Write a test to recreated the bug - this test will pass. 3. Write a test to test how the code whould work - this test will fail. 4. Fix the bug. 5. The first test will now fail as the bug is fixed and the second will pass. Do I keep the first test that recreated the bug? It would be good to keep it as part of the history of how the bug was fixed but I wouldn't want to keep on running a failing test. Rereading a bit of your book again (the Prove a Bug is Recreatable and Prove a Bug is Fixed sections) I might have misunderstood steps 2 and 3. It looks like you might be writing a test to recreate the bug (DivideByZeroException) in your example and then you change the test to test what should happen (ArgumentOutOfRangeException). So it's one test rather than two. Stephen
-
Hi Marc Thanks for the reply. I guess my question is more about the process of bug fixing. This is how I think it goes. 1. A bug is reported. 2. Write a test to recreated the bug - this test will pass. 3. Write a test to test how the code whould work - this test will fail. 4. Fix the bug. 5. The first test will now fail as the bug is fixed and the second will pass. Do I keep the first test that recreated the bug? It would be good to keep it as part of the history of how the bug was fixed but I wouldn't want to keep on running a failing test. Rereading a bit of your book again (the Prove a Bug is Recreatable and Prove a Bug is Fixed sections) I might have misunderstood steps 2 and 3. It looks like you might be writing a test to recreate the bug (DivideByZeroException) in your example and then you change the test to test what should happen (ArgumentOutOfRangeException). So it's one test rather than two. Stephen
Yes, exactly, I think its one test rather than two. Marc
-
Yes, exactly, I think its one test rather than two. Marc