in reply to File dynamic write operations

Is this a better approach ?

There is no "better or worse" approach here based upon your problem statement. Given that you can do either, I would use the easiest one, which I would guess is method 1? If not then use method 2.

Now of course how difficult your output format is for the "consumer to consume" is something to be considered. There is not a "one size fits all" answer for this. Sometimes it makes more sense for your program to do more work so that other programs have to do less work and sometimes not!

Can you put some more "flesh on these bones" so that some application specific recommendation can be made? There is no generic A is better than B for this sort of thing.

Replies are listed 'Best First'.
Re^2: File dynamic write operations
by perlpal (Scribe) on Aug 16, 2010 at 09:28 UTC

    Adding a little more detail.

    I am auto-generating unit test cases which are native to an automation framework. These test cases have static parts(hardcoded) as well as dynamic parts.

    The static parts are the subroutines like init() , uninit(),setup() and cleanup().

    The dynamic parts are the subroutines for the unit test cases themselves.One sub routine is written per feature CLI . These subroutines are identified after processing the product CLI for each feature.

      I think I understand what you are doing. And it appears to me that an output that follows the natural time order of how the various routines are called would be best with an eye towards making each test as independent as possible from the other tests.

      If a test fails, the developer will want to know a) if you can repeat it and then b)given that you can do that, can you repeat it with the smallest data set and number of dependencies possible? Hopefully the printout should be a really good starting place for (b). So if you are asking if it is ok to have "redundant" information in the output? I would say yes!

      If some other person in some other department is running your tests, it is often a very good thing if he winds up with a contiguous set of text that can be snipped out and sent to you when "something goes wrong". So say if you run init(),test1(),init(),test2... Presumably init() does the same thing every time, but by repeating this information in the output, the sequence that caused the problem is all connected in a contiguous way. And I would prefer that over: here's what init() does and then way down in the printout, here's what test1(), test2() did.