Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
I Hope This Helps
Carl Trusiak, SCJP2, SCWCD
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
We also use JBuilder and Emacs for our development.
I've looked into JUnit. Here's the problem I see using it here. We have a fairly complex framework. I think it's reasonably well done, bot too tangled, but still complex. Needless to say it is not easy to create a single object in isolation, because that object requires another object, and so forth. (Note, one object doesn't directly require, say, another 5, but it may "chain" through to requiring another 5.) Bottom line, getting started to do some basic tests require a lot of setup and overhead.
I'm wondering it it's possible/feasible, to put some "unit testin" type code into our code base, i.e. methods at the end of the class, which are normally commented out, when not being used.
I've been skepical of pair progamming, but think this may be a case where it would work well, so I'll give it a try.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Then you might want to take a look at JRefactory: http://jrefactory.sourceforge.net/csrefactory.html
Seems to me as if mock objects might help. See http://www.junit.org/articles.htm#MockObjects and
http://tammofreese.de/easymock/index.html
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Actually in the "old days" we would create specs which you could code directly from. That was my initial point, that these interum steps are no longer done which has impacted the quality of software.
I have always believed in cross-training, and for that purpose it would be fine ( as well as the previous points). But do you advocate that everything which is coded needs to be coded by two people?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
- What tools do we need?
I read the Mock Objects paper. This idea seems obvious. I thought of that, too, that I would create these dummy fixtures I could use in my tests. However, it, in and of itself does not solve my problem. The interface to the Mock Object may require passing MyClass1. The constructor of MyClass1 may need MyClass2 and MyClass3. Now I need to create 3 Mock Objects for a single unit test! Given that Mock Objects aren't simply isolated stub classes, I would effectively need to maintain a shadow, mock framework, so that any test I could need to do could be run against the mock framework (minus the part being tested). My maintanence work has doubled, since now I must maintain two frameworks. Also, again given that these Mock Objects aren't isolated stub classes, I am likely to make errors while creating them, making my unit tests inaccurate.
I'm not inclined to register so I can participate directly, but I do
have a comment (feel free to post it there if you like).
The OP talks about needing to manage a whole parallel framework if he
does MockObjects... his example is where Class1's constructor needs
Class2, which needs Class3 and Class4, etc. I want to point out that
the "fix" for this is to have the Mock _NOT_ depend on Class2 etc.
Extract the public interface (not the constructors) of Class1 into
Interface1, then except where it's constructed, use and refer to it by
the interface. If the constructor is called inside the code under
test, you'll need to either move it out of there, or use a factory.
If the constructor is called outside the code under test (e.g., the
object is passed in), then your test code can just construct and pass
in the mock instead of the real object.
One of the huge benefits of Mock objects is that they can cut the
dependency chain short... you only need to mock the objects that the
code under test calls _directly_.
-Matthew
azami@speakeasy.net
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
azami@speakeasy.net wrote:
his example is where Class1's constructor needs Class2, which needs Class3 and Class4, etc. I want to point out that the "fix" for this is to have the Mock _NOT_ depend on Class2 etc.
Extract the public interface (not the constructors) of Class1 into Interface1, then except where it's constructed, use and refer to it by the interface. If the constructor is called inside the code under test, you'll need to either move it out of there, or use a factory. If the constructor is called outside the code under test (e.g., the object is passed in), then your test code can just construct and pass in the mock instead of the real object.
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Don't get me started about those stupid light bulbs. |