It does make sense to just archive up the test files. When applying,
we generally just copy the few files from the NH#### folder and paste
them into a folder in NHibernate.Test. If people want to submit the
test more directly, a pull request against the main repo would work.
As I mentioned in another message, there's now a Contributor Guide in
the NHibernate source that shows how to easily make such a test.
IMHO, it's not a significant difference in effort, and doesn't involve
redoing work if you suddenly get the itch to try fixing it.
To summarize my viewpoint, here are the steps that differ for each:
Separate Test:
1. Download and unarchive or clone test repository.
2. Edit hibernate.cfg.xml for your database. If it's not SQL server
this will involve more steps as the alternate configurations are not
at hand. You will also need to find whatever dlls are pertinent for
your database and either reference them or copy them to your output
folder.
3. Make your test by editing the existing files.
4. If you don't have a third party test runner like ReSharper, you'll
need to add code to run your test and determine the results.
5. Archive the test.
6. Attach the test as a zip file on the issue.
NHibernate Core (following the Contributor Guide directions):
1. Clone the main repository.
2. Use the build menu to set up a configuration for your database.
Multiple alternative databases are supported out of the box, so you
can more easily attempt your test against different databases. The
recommended settings and assemblies for each database are already
present, so it's usually just a matter of editing the connection
string. Simple as A, B, C. ;)
3. Copy and paste the NH0000 test.
4. Make your test by editing the existing files.
5. Run the test, even if you don't have a third party runner
installer, by starting the test project in the VS debugger. The
included NUnit GUI is started automatically.
6. Commit.
7. Submit a pull request.
8. Link to the pull request from the issue.
Steps 6-8 could be replaced with an archive of the test folder if
desired. It's just that in this scenario, the pull request can have
discussion and futher commits with almost no effort.
So, in essence, if you're willing to wait longer for the download, the
nhibernate-core repo lets you configure and run your test more easily,
and allows for multiple commits to work out any kinks. Since it's in
context, you can also be sure that your test has not had side-effects
that broke other tests and you can immediately start debugging
NHibernate.
I can imagine it being made even easier, for example, condensing the
build menu steps and copying of test into a single batch file for the
simple case. Doing this would condense steps 2 and 3, making it
basically the same basic steps as the separate test project.
Maybe my head is in the clouds, but I like to think that we can have
our cake and eat it too if we're willing to put up with the longer
download for the core. I'm happy to hear people's thoughts around
this. Would love to make the contribution process very smooth.
Patrick Earl
