settings for compiling separate release and debug versions

[Doug Slattery]

Aloha ranchers,

I'm drawing a blank right now on this.

I've started helping on an existing project of which testing will be a problem for me the way it currently is. The problem is the app can't run locally and needs to be deployed to a development server for testing by another department. The reason is the database is on an AS400 behind a firewall and you need to login to the app via the database. There is an abstraction layer between the main code and the database code, which makes since to put some dummy code to simulate the database. In 'C', I'd do it something like this:

/* abstraction layer database code */
#ifdef TEST_LOCAL
  /* dummy code */
#else
  /* existing code */
#endif

Does Java have something similar to the gcc -D flag (i.e. gcc -DTEST_LOCAL ... or #define TEST_LOCAL)?
For extra credit, we're using Eclipse here and setting it up there will be my next hurdle

Aloha,
Doug

-- Nothing is impossible if I'mpossible

[vu lee]

Depend on what type of testing you want to run. You could do a local in-memory test by using EasyMock or JMock to create database access objects.

[Jeanne Boyarsky]

Doug,
Mocks are good for unit testing. You still need some way of integration testing locally though. I recommend using a different database (that you control) with the same schema. You can use a datasource or property file to use different databases in the different environments (local testing, the other department's database, production, etc). This way you are exercising the same code in both release and debug versions. The more that is different, the more that can go wrong.

For the few situations where I have a small amount of code that I can't test locally, I'll do something like this:

public void methodAccessingHeaders() {
if ( propertyFileSetToTestMode ) {
  // hard code values
} else {
  // call another method
}

Then I unit test the "another method". Not as good as integration testing, but suits my purposes for a simple piece of code. For a database, I wouldn't go this route. I would use my own database.

[Nicholas Jordan]

For what it's worth, my two cents.

An author with a Doctorate in cs and published author in aw professional suggests doing private static final boolean debug; at the top of (each) file and then doing if(debug){}

The author ( that's not the only one to suggest this - one of them wrote a Gotcha book after decades of dealing with this type of thing ) states that any nimwit or above compiler competency should recognize and optomize away all unreachable code such as if(false){}.

The others have to do database programming, I do not - so there may be other issues I have no exposure to.

[Doug Slattery]

Thanks for the replies vu & Jeanne.

I took a look at EasyMock and jMock, but it's not really what I need. I probably should've mentioned in my first post this is a web app (my bad). The code I want to dummy up (the database code) I don't care about. I need to get around it so I can get to the code I want to test without the database code failing and stopping me from getting there.

As an example, suppose I want to check some behaviorism of the browser by selecting a link to another page. This behaviorism doesn't access the database, but the user needs to be logged in. For the user to be logged in, they would have accessed the database at the login screen. The steps to get to where I need to be would fill in session information and other things, so I can't just go to the page and click it. Only when I get around the database problem will I be ready for unit testing (which I want to do locally). The dummy database code will just fill in values along the way so the app doesn't get derailed.

It would be great if there's something in Eclipse/javac that can be done through the project properties or environment without having to remember to change a test/production flag in some master class.

I hope that makes sense...

@Jeanne: Your example

public void methodAccessingHeaders() {
if ( propertyFileSetToTestMode ) {
  // hard code values
} else {
  // call another method
}

is right in line with what I need to do to the database code to get me to my unit testing point. However, I also would like the propertyFileSetToTestMode field in your example to be set at compile time, preferably by the compiler.

I'm still kind of green when it comes to things like this in Java.

@Nick,

An author with a Doctorate in cs and published author in aw professional suggests doing private static final boolean debug; at the top of (each) file and then doing if(debug){}

That's just sooooooo not practical to this nitwit or project. Seems to me that #define's in 'C' were created for just this purpose .

The others have to do database programming, I do not

Neither do I, but it's in the way .

@whoever moved my original post. Thanks for letting me know. A courtesy post would've been nice since I've been F5'ing the original post all afternoon (and the redirect message at the top of the page was scrolled off) .

Aloha,
Doug

-- Nothing is impossible if I'mPossible

[Jeanne Boyarsky]

Originally posted by Doug Slattery:
is right in line with what I need to do to the database code to get me to my unit testing point. However, I also would like the propertyFileSetToTestMode field in your example to be set at compile time, preferably by the compiler.

Why? In Java, property files are a pretty standard way of doing things. What benefit does a compile time setting give you that a property file does not? Note that we typically read in the property file once (so we aren't dealing with IO all the time) and access that singleton to get the property at runtime.

There is another Java alternative, which is to set the value as an argument or system property (-d parameter.) These are more frequently used for stand alone Java programs than web apps though.

In Java, it is common practice to avoid changing the app for environment/property type settings. Which is why I'm curious what benefit you are trying to obtain.

without having to remember to change a test/production flag in some master class

Don't you need to remember to change

@whoever moved my original post. Thanks for letting me know. A courtesy post would've been nice since I've been F5'ing the original post all afternoon (and the redirect message at the top of the page was scrolled off) .

That was me. I'm sorry - I usually do add the post explaining that/why I moved it. I was so focused on replying that I forgot to this time.

[Doug Slattery]

Hi Jeanne,

Thanks for chiming in again...

Why? In Java, property files are a pretty standard way of doing things. What benefit does a compile time setting give you that a property file does not?

Right now, I'm property file challenged (that is I've never used them before), so I can't answer that. I'll read up on them so I can talk intelligently and come back.

I don't know if my approach is the best way in Java, so that's why I'm asking. I'm trying to do it the same way I do in 'C', which may not be the best way in Java :s . In 'C', I'd have some code (like my original post example) that would compile one way if a compiler directive was set, or another if not:

#ifdef THIS_WAY
  /* compile this chunk of code if THIS_WAY is defined */
#else
  /* otherwise compile this chunk */
#endif

Then, I'd have two build scripts (or Makefiles), which one would build with THIS_WAY set and the other with it not set. No need to set a global variable as in Nick's example. Then, when I wanted to build a distro, I could simply type in something like:
$ make THIS_WAY_target
or
$ make
In the first way, make THIS_WAY_target, the Makefile contains a target build section with an id of THIS_WAY_target, and the section sets up all the compiler directives to set the THIS_WAY definition that will compile the corresponding code chunks. That way, all I have to pay attention to is the type of distro I'm building (by only the command line) and not having to worry about changing things here and there in the project or worse, in the code. Visual C/C++ has a similar thing in their ide, and you just need to create two projects to do it this way. Nothing to remember (or forget) at build time. Once the build is done, everything is done. Nothing to set or worry about in the runtime environment.

That was me...

LOL, egg-on-my-face

Aloha,
Doug

-- Nothing is impossible if I'mPossible

[Jeanne Boyarsky]

Originally posted by Doug Slattery:
That way, all I have to pay attention to is the type of distro I'm building (by only the command line) and not having to worry about changing things here and there in the project or worse, in the code. Visual C/C++ has a similar thing in their ide, and you just need to create two projects to do it this way. Nothing to remember (or forget) at build time. Once the build is done, everything is done. Nothing to set or worry about in the runtime environment.

The nice thing about high level goals is that they don't change by environment. Separating out what you want to accomplish (a way of flagging whether to execute a piece of code) and why (to avoid changing the code) are things I absolutely agree with!

I have used C++ in the past, although it's been a while. And I definitely agree that the settings should be done at build time. i think that word might mean something slightly different to us though. As I recall, the traditional definition of "build" in C++ was the make file and compile. In Java, "build" is the process of creating a deployable artifact (war or ear file in this case.) It can be done with Ant, Maven, a custom script or IDE. The IDE is the most manual of these as you have to enter the same settings each time. The reason I go into this distinction is that our team includes "property file generation" in the build process. I like having things specified once rather than have to do them every time I build.

ps - I like your signature!

[Roger Chung-Wee]

I know nothing about Makefile, but I've spent a fair amount of time writing Ant scripts. If you want to build your distribution JAR files with Ant, it's very easy to pass parameters to Ant by setting properties on the command line. You can also set one or more targets to be executed at the same time.

[Doug Slattery]

Thanks Jeanne & Roger.

Since I'm still faced with the same problem, but more wisdom now, I'll roll with it for the next week or so. This week ends my first week at this new job and things are coming at me too fast & furious, although I'm holding my ground at the expense of burnout.

They are using Ant, but I haven't had the chance to start diving into it. If it's like everything else they've thrown at me, it'll take no time. Since I'm working with other people, I want to be sure what I'm going to do makes sense, rather than, well, use your imagination here ...

At least so far as this thread has gone, it seems I can't do what I want the same way in Java as what I'm used to. It's not a frustrating feeling, but along those lines. I'm sure you know what I mean.

Anyway, I need to get back to home improvement to take my mind off it for a while... Unless anyone else has "too sense" to add, I'll be back later to follow up.

ps - I like your signature!

Wait 'til you see ... Oh wait, that might make some people blush.

Enjoy the rest of your weekend!
Aloha,
Doug

-- Nothing is impossible if I'mPossible

[Nicholas Jordan]

Originally posted by Doug Slattery:
Thanks for the replies vu & Jeanne.....( snip )...

Aloha,
Doug

-- Nothing is impossible if I'mPossible

I took a look at EasyMock and jMock, but it's not really what I need. I probably should've mentioned in my first post this is a web app (my bad). The code I want to dummy up (the database code) I don't care about. I need to get around it so I can get to the code I want to test without the database code failing and stopping me from getting there.

Recode with ( I am assuming Java, it has a fundamentally safer api than C/C++ you are used to - and was built, more correctly evolved - to address exposures that were left out of C++ for people who needed to write os's without Anitlock Braking System making the pedals go spongy every time you worked at the limit ) .... Recode with the stubb ( dummy coded ) as an available call using a default visibility class in the same file as the behaviorism that accesses the database, take it out with a final static boolean in the calling class to do if(debug){}else{}, the else is the release verson.

You then invoke the app ( call the main() class from the jvm command line ) with some version of

public static void main(String[]args{
Server dummyDatabase  = new Server(boolean testing);
WebApp doLocally = new WebApp(dummyDatabase );// can now access Server
/***** Additionial Threading or other matters addressed with additional code *****/

You can now code and recode without the database code failing and stopping ... ( stopping code concepting and testing )

As an example, suppose I want to check some behaviorism of the browser by selecting a link to another page. This behaviorism doesn't access the database, but the user needs to be logged in. For the user to be logged in, they would have accessed the database at the login screen. The steps to get to where I need to be would fill in session information and other things, so I can't just go to the page and click it. Only when I get around the database problem will I be ready for unit testing (which I want to do locally). The dummy database code will just fill in values along the way so the app doesn't get derailed.

Well, sort of. There are several issues here - which I will put a handle on by mentioning the time I was logged onto an https site and closed one or two browsers withing a few hundred milliseconds of one another and had the os do a select(window); that suggests that we explore the security capabilities of applets. Applets, which I trust much farther than the browser ( this is one coder talking to another, not the help call from hell ) because the applet can talk to the server remarkably freely and will not under a base implementation write something to persist(); that can be found by Next User and Average Access. Additonally, there are real cryptographic protocols available for use in Java code that have been extensively tested by real-world use. The beauty here is if the WebApp gets worked on the client-side by the normal use patterns, we have here a strong barrier wall that can be used to shield the database from nimwit mice.

If your app nimwits a commercial database, burnout will not matter.

It would be great if there's something in Eclipse/javac that can be done through the project properties or environment without having to remember to change a test/production flag in some master class.

I will let the others promote the well established tools, I just write raw code and leave the issues in yesterday.

@Jeanne: Your example

public void methodAccessingHeaders() {
if ( propertyFileSetToTestMode ) {
  // hard code values
} else {
  // call another method
}

is right in line with what I need to do to the database code to get me to my unit testing point. However, I also would like the propertyFileSetToTestMode field in your example to be set at compile time, preferably by the compiler.

Do it by invocation command line ( possibly ). java app -debug

You are gonna have to remember something somewhere, or have some random string you put into a text box during testing to invoke debug. App can be place in administrative mode or whatever you can remember keys for. In general, I do a check for common passwords, then if string.length == 64, check for a keyset of some hundred or so keys ( using the hashcode: DO NOT STORE THE KEYS IN THE APP !!! ) and if the logon username / password are not in the area of what most any normal user would keyboard into the app, we either pass the logon to real engineers with some baseline experience in cryptographic work or just exit and make an entry in the logs or someting, in other words: Do what normal people do.

I have significant experience with key management, keys should either be breakable or master's level mathemeticians with 5+ years field experience in cryptographic work do the shields, your real problem is the greymeat between the human ears. The depth of this challenge goes through several inversions before we can even begin real work here.

I'm still kind of green when it comes to things like this in Java.

Java will rule all of computer science within a few decades, get in early on the next evolution of societal progress.

Neither do I, but it's in the way .

You only think it's in the way. Again, the human greymeat. Take ten minutes during your next lunch and consider employment on the Tunguska Fur Trapping Practices Improvement Comittee, run by Igor Knuckleosrski and contrast that to an imaginary opportunith to submit resume for consideration on the Non-Deterministic Finite Automa Comittee for the proposed Ultra-Linear Waveguide Comittee. Do this while watching the news and look down at your plate. It has food on it.

#ifndef dewine
#define dewine devine
#elsedefine dewine declined

You'll never have to code the above if you screw up, nor consider private static final boolean debug = true/false.

Vulnerability Analysis and Defense for the Internet
Series: Advances in Information Security , Vol. 37
Singh, Abhishek (Ed.)
2008, XVI, 256 p. 20 illus., Hardcover
ISBN: 978-0-387-74389-9

Available now at a bookstore near you.

[ Message edit by Nicholas Jordan: see what this guy did: mail server test stubb ]
[ January 30, 2008: Message edited by: Nicholas Jordan ]