How does one test generated code

0 views
Skip to first unread message

Ben Hughes

unread,
Jun 12, 2008, 7:30:16 PM6/12/08
to RubiGen
Excuse me if I am missing something obvious, but I just can't seem to
figure out a good way to do overall testing of generated code. The
standard application and component generator test stubs are great for
verifying that the generator is behaving properly and creating the
right files, but I can't figure out a good way to test the actual
generated files.

I have an application generator that creates a simple framework with
code and all for database access and whatnot. It then has component
generators for tasks, models, migrations, etc. I want to test the
creation of a new project and then some sample workflows like
generating new models, migrating the dbs, and running sample tasks. My
naive approach was to try to Dir.chdir into the folder generated
through run_generator and run code out of there, but this does not
seem to work.

My next thought was to create a framework test generator that could
fill a created project with these required tests, but I don't know how
I would cause those to be run as part of my ordinary tests.

RubiGen is a fantastic tool and it has proven to be a real boon to my
productivity. I am sure I am just missing something with the testing
situation and I would be much obliged for any help or pointers I
receive on this matter.

Ben Hughes

Nic Williams

unread,
Jun 12, 2008, 8:34:37 PM6/12/08
to rub...@googlegroups.com
Yeah I've had vague thoughts about running tests over the generated code (above and beyond the current testing of "assert_generated_file" etc that you can currently do)

The challenge with generators is I never seem to write enough of them to experience enough pain to want to fix some things.

But, a framework for setting up a test of generated code/files would be awesome.

Perhaps: run the generator in a test file's setup method into a test/tmp folder. Then, in the same setup method, load/require in the target file(s). Now the test_X methods are running on the generated code, rather than the gem itself.

You could do this without a framework to help, and once you done one or two, reply back with a url to the src so we can have a look. Perhaps something can be refactored into rubigen.

Nic
--
Dr Nic Williams
* Learn TextMate for Rails2 - http://peepcode.com/products/textmate-for-rails-2 *
Training in Ruby/Rails/JavaScript - http://drnicacademy.com
Fun with Ruby/Rails/Javascript - http://drnicwilliams.com
Photos of our new daughter & family- http://flickr.com/photos/drnic

Ben Hughes

unread,
Jun 13, 2008, 10:29:26 AM6/13/08
to RubiGen
Ok, I have some form of testing working. It's a bit confusing trying
to keep all the paths absolute rather than relative in the generated
code, but I have it so things go. I'm just playing with it now, but
if I can extract patterns and the like, I will.

You can see the current state of the tests at
http://github.com/schleyfox/gigantron/tree/master/test/test_gigantron_generator.rb#L47-106
. They are not much now, but they do exercise my db connection and 2
of my generators.

Thanks for your suggestions.

Ben Hughes
> Fun with Ruby/Rails/Javascript -http://drnicwilliams.com

Nic Williams

unread,
Jun 13, 2008, 2:19:56 PM6/13/08
to rub...@googlegroups.com

http://github.com/schleyfox/gigantron/tree/master/test/test_gigantron_generator.rb#L56-62

Another option here is to create the YAML with the library. BTW, what is GTRON_ROOT vs APP_ROOT?


http://github.com/schleyfox/gigantron/tree/master/test/test_gigantron_generator.rb#L56-62

The creation of Foo.new.save (btw - Foo.create(:title => t) is the same) - in a migration could go in a 2nd migration, thus not destroying the original migration which you are testing (I guess).


Cool stuff.

* Learn TextMate for Rails2 - http://peepcode.com/products/textmate-for-rails-2 *
Training in Ruby/Rails/JavaScript - http://drnicacademy.com
Fun with Ruby/Rails/Javascript - http://drnicwilliams.com

Ben Hughes

unread,
Jun 13, 2008, 3:48:25 PM6/13/08
to RubiGen
GTRON_ROOT is just the root of the gigantron app, it is set by the
generated code. I should probably not mix and match. The only
difference between the YAML generated in the test and that created by
the app_generator is that the app_generator one uses a relative url to
the db. I might change that later.

I've just been kind of hacking at it, trying to get things to work, so
things will definitely be cleaned up.

Thanks for the help and the feedback. I think I will now be able to
test my code more or less properly.

Ben Hughes

On Jun 13, 2:19 pm, "Nic Williams" <drnicwilli...@gmail.com> wrote:
> http://github.com/schleyfox/gigantron/tree/master/test/test_gigantron...
>
> Another option here is to create the YAML with the library. BTW, what is
> GTRON_ROOT vs APP_ROOT?
>
> http://github.com/schleyfox/gigantron/tree/master/test/test_gigantron...
>
> The creation of Foo.new.save (btw - Foo.create(:title => t) is the same) -
> in a migration could go in a 2nd migration, thus not destroying the original
> migration which you are testing (I guess).
>
> Cool stuff.
>
>
>
> On Sat, Jun 14, 2008 at 12:29 AM, Ben Hughes <schley...@gmail.com> wrote:
>
> > Ok, I have some form of testing working.  It's a bit confusing trying
> > to keep all the paths absolute rather than relative in the generated
> > code, but I have it so things go.  I'm just playing with it now, but
> > if I can extract patterns and the like, I will.
>
> > You can see the current state of the tests at
>
> >http://github.com/schleyfox/gigantron/tree/master/test/test_gigantron...
Reply all
Reply to author
Forward
0 new messages