|
Of course you need to write code. The unit test is created with defaults; its up to you, the developer, to actually make it relevant.
No comment
|
|
|
|
|
*bang* *bang* *bang*
The thing I love about banging my head on the desk, is the wonderful feeling you get when you stop... 
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Yes, I need to write some code to meet the TDD requirement. I don't want to write code every time I generate a TDD unit test. I think I have a solution here, i.e., adding the minimum TDD code to a new test project template called "TDDUnitTest".
Best,
Jun
|
|
|
|
|
TDD != Unit test. You first need to understand that very important concept.
Jun Du wrote: I don't want to write code every time I generate a TDD
Then you are in the wrong profession and/or don't understand what TDD is
*bang* *bang* *bang* This feels good 
No comment
|
|
|
|
|
Mark Nischalke wrote: Then you are in the wrong profession and/or don't understand what TDD is
Both of your assumptions are wrong. That's why we try not to make assumptions during a debate!
My question was "how to make all tests fail initially without manually writing code". I was hoping to apply the Unit Test framework to TDD. I think I got what I was looking for.
Best,
Jun
|
|
|
|
|
Would you care to elaborate. You have got me interested in this TDDUnitTest idea.
"You get that on the big jobs."
|
|
|
|
|
Basically, to meet the specific TDD requirement under discussion, I would create a sample unit test project that handles two initial cases:
1) Check the app.config file and see if the class being tested has been coded. In order to do that, you need to add a key to the config file and set it to false initially. Of course, some more intelligent alternative can be implemented if you feel like to.
2) As Ravi suggested in his message below, have each of the unfinished methods throw an "unimplemented" exception. Add a handler to the test code to capture this and fails aumatically.
After you have the above minimum test code in place, create a project template and an item template, called "TDDUnitTestPlroject" and "TDDUnitTest" respectively. From now on, you can use these templates for TDD unit test projects and you don't need to write the same code again and again.
Best,
Jun
|
|
|
|
|
Yes. One way to do this is to make the methods being tested throw NotImplementedException. As you build out your code, your tests will eventually pass (once you've identified and fixed detected bugs). Of course, you also need to perform system (vs. unit) testing to help ensure product quality.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: One way to do this is to make the methods being tested throw
NotImplementedException.
Yes, that would work for each of the unfinished methods after the class is coded.
Ravi Bhavnani wrote: Of course, you also need to perform system (vs. unit) testing to help ensure
product quality.
Absolutely. Usually, unit test is tedious and costly. By using some sort of test framework, we could simplify and automate the process significantly.
Best,
Jun
modified 9-Jan-12 9:33am.
|
|
|
|
|
The approach you seem to be describing here is not TDD though. You don't start with a coded class, you start with the tests and build your functionality out of this. What am I missing in your solution that makes it suitable for TDD?
|
|
|
|
|
I start with classes that contain unimplemented methods, causing their tests to intially all fail.
/ravi
|
|
|
|
|
If you strictly follow TDD, then your first tests don't actually have any corresponding methods.
|
|
|
|
|
You could add the test method before you implement a method. You did the same with classes. I think this is what "write test first, then write code" really means.
You also could create method signatures (input/ouput parameters and return type) without method body. After having the method signatures, you can write the test method to test the method.
Best,
Jun
|
|
|
|
|
I don't really understand this question. If you're using fundamentalist TDD, you should write the tests first, before you have any code, and so there is nothing for automated code generation to work with. (A full scale TDDer would write tests that don't even compile before writing the methods that it references.) And if you're not, don't worry about this rule, just write the content of the test so that it actually ... well, tests stuff.
|
|
|
|
|
BobJanova wrote: If you're using fundamentalist TDD, you should write the tests first
Yes, that is exactly how we started. For TDD, you create a test project using VS 2008 (or NUnit, etc). You notice that your test project actually compiles and runs successfully, even without implementing your souce project.
In terms of TDD, the common problem with most test frameworks is that before you write the source project, your test project won't fail. Of course, this is kind of formal TDD requirement that many people don't care.
Best,
Jun
|
|
|
|
|
Jun Du wrote: You notice that your test project actually compiles and runs successfully, even
without implementing your souce project.
And that's exactly the way it should be. TDD doesn't say that your test project should fail, it says that the actual application code starts off by failing and you add tests and code in harmony.
|
|
|
|
|
I think you have misunderstood something about TDD here. As Pete says, TDD doesn't specify that the project should fail, it specifies that individual tests should fail when you first write them. An empty project contains no tests, and so (obviously) nothing fails, but that's because you haven't written any tests and therefore (in pure TDD) your program has no requirements.
|
|
|
|
|
I think I understand TDD correctly. The test project is a wrapper of one or more tests. When I said that the test project fails, I meant that one or more tests (or test methods) fail.
This is the TDD workflow I use:
1) Add a test
2) Run the test
2.1) if the run succeeds, go to step 1).
2.2) if the run fails, write some source code; go to step 2).
3)Done
Note that the source code is the unit under test, not the test itself. Don't confuse TDD with normal unit test. In TDD, we create the unit test before creating the unit. The unit test should not pass before we have the unit.
Best,
Jun
|
|
|
|
|
Yes, that's correct, but until you write a test it makes no sense to worry about whether the test project compiles and runs. Actually one could argue that it should succeed because with no tests, your program has no requirements and so it will pass them all (it's easy to do nothing).
|
|
|
|
|
I am getting an odd result when trying to decompress .gz files... The method that I am using only decompresses the first 24KB of the file, but the actual content is over 100 MB.
I am using .NET 3.5, with the decompression method from the MSDN article (copied below). Has anyone seen this odd behavior before..?
private static void gDecompress(FileInfo file)
{
using (FileStream inFile = file.OpenRead())
{
string curFile = file.FullName;
string origName = curFile.Remove(curFile.Length - file.Extension.Length);
using (FileStream outFile = File.Create(origName))
{
using (GZipStream Decompress = new GZipStream(inFile, CompressionMode.Decompress))
{
byte[] buffer = new byte[4096];
int numRead;
while ((numRead = Decompress.Read(buffer, 0, buffer.Length)) != 0)
{
outFile.Write(buffer, 0, numRead);
}
}
}
}
}
|
|
|
|
|
Timothy CIAN wrote: Has anyone seen this odd behavior before..?
I haven't.
I did look into MSDN a bit, and I noticed the code examples for 2.0, 3.5, and 4.0 are all different, although I can't tell why; they all look good to me.
[ADDED] I also ran the 2.0 example on a 1.5MB file, and all was well.[/ADDED]
What makes you think the decompression terminates early? Are you sure the input file is what you intend it to be, maybe you are using similar code and it has a bug somewhere. I suggest you add (re-insert) debug statements, then compare the original uncompressed file size, the compressed one, and the final decompressed one.
modified 6-Jan-12 13:13pm.
|
|
|
|
|
Well, I have it attempting to decompress a collection of .gz files which are generated as output from a 3rd-party application. However, since I don't see anyone else (via Google search) having this problem, I shall assume it is either (1) something odd about how the 3rd-party source is (mis)creating .gz files, or (2) something is wonky elsewhere with the code. #2 seems unlikely, as this is a static method that only takes a FileInfo as input. It seems fairly self-contained.
However, my next step is to create a tiny app that I can test this with (in better isolation from the "other stuff" in my code), as well as a parallel test using something like SharpZIPlib to see if there is any difference.
Thanks...
|
|
|
|
|
Update...
The .gz appears fine; I was able to extract it using WinZip (224 MB -> 877 MB). I tested Ionic's version of GZipStream, and it also resulted in a 24K file, along with the following error message:
Destination array was not long enough. Check destIndex and length, and the array's lower bounds.
Here is the Ionic-GZipStream version (which is almost identical to the previous):
private static void gDecompressIonic(FileInfo file)
{
using (FileStream inFile = file.OpenRead())
{
string curFile = file.FullName;
string origName = curFile.Remove(curFile.Length - file.Extension.Length);
using (FileStream outFile = File.Create(origName))
{
using (Ionic.Zlib.GZipStream Decompress = new Ionic.Zlib.GZipStream(inFile, Ionic.Zlib.CompressionMode.Decompress))
{
byte[] buffer = new byte[4096];
int numRead;
while ((numRead = Decompress.Read(buffer, 0, buffer.Length)) != 0)
{
outFile.Write(buffer, 0, numRead);
}
}
}
}
}
|
|
|
|
|
Timothy CIAN wrote: The .gz appears fine; I was able to extract it using WinZip
Maybe the creator is using winzip rather than a gzip library. And winzip itself is doing something odd.
Did you try a straight gzip utility?
|
|
|
|
|
Does the file use Deflate64?
WinZip handles that, but almost nothing else does.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
