Config templating and unittests within Visual Studio (using Resharper, TestDriven.Net ...)

[Jan V]

Hello,

Is it possible to combine the use of a templated configfile (say hibernate.cfg.xml.template) with running all the unittests (also those needing configuration) in Visual Studio?

What I want to achieve is:

1. <build.bat>
   
2. <open.bat>
   
3. "Run all tests from Solution" (Resharper)
   
4. Everything green
   

But step 4 fails because in the output folder the file hibernate.cfg.xml is not present (see [1]), only the still to be de-templated .template files...

However I don't want to add a hibernate.cfg.xml file (pointing eg. to the local database) to the project because:

•  Not everyone has the same sql-server instancename (.\sql2005 <> .)
  
•  I don't want to risk having a hibernate.cfg.xml file in my code_drop because if I forget to overwrite it in my deployment script a file with development values get deployed.
  

I was thinking about adding a post environmentbuilder step to use a special setting file (specific for each developer and not to be checked into source control) and use something like the BuildTemplateFiles task ...

Any pointers or advice?

[1 : project structure after building]

--8<--

|   build.bat

|   open.bat

|   SolutionVersion.cs

|   SolutionVersion.vb

|   test.bat

|   UpperCutPOC.sln

+---build

+---build_output

|   |   build.log

|   +---environment.files

|   |   +---LOCAL

|   |   |       LOCAL.configfile.txt

|   |   |       LOCAL.hibernate.cfg.xml

|   |   \---QA

|   |           QA.configfile.txt

|   |           QA.hibernate.cfg.xml

|   \---UpperCutPOC

|           Dll's and pdbs ...

|           configfile.txt.template

|           hibernate.cfg.xml.template

+---code_drop

+---settings

|       LOCAL.settings

|       QA.settings

|       UppercuT.config

\---src

    +---Application

    |   |   Application.vb

    |   |   Application.vbproj

    |   |   configfile.txt.template

    |   |   hibernate.cfg.xml.template

    +---Application.TestFixtures

    |   |   Application.TestFixtures.vbproj

    |   |   When_doing_something_fast.vb

    +---Application.TestFixtures.Integration

    |   |   Application.TestFixtures.Integration.csproj

    |   |   When_calling_method_needing_configuration.cs

    |   |   When_running_this_long_test.cs

    |   |   When_running_this_obscenely_long_test.cs

    +---Library

    |   |   BtwCalculator.cs

    |   |   Library.csproj

    |   |   Product.cs

    +---Library.TestFixtures

    |   |   Library.TestFixtures.vbproj

    |   |   When_calculating_Btw_for_luxury_product.vb

    |   |   When_calculating_Btw_for_regular_product.vb

    +---Repository

    |   |   Repository.csproj

    |   |   SomeTypeRepository.cs

    |   +---MappingFiles

    |   |       Product.hbm.xml

    \---Repository.TestFixtures.Database

        |   Repository.TestFixtures.Database.csproj

        |   When_getting_all_from_repository.cs

-->8--

[Rob Reynolds]

What about using something like SQLite for automated testing? Putting on my unit testing principles hat for a second...

<rant>

Testing with external elements like a database is integration testing since you are stepping outside of code. Integration testing is less maintainable than unit testing (single units of code). If it is really important to you to have these integration tests, then it is important enough that every one should have the same local environment setup (i.e same database instance (local) or (local)\SQLExpress). Then you don't have to make it harder on yourself attempting to maintain a losing battle.

</rant>

Really in the end you want your local environments in sync. It will enable things like testing your deployments locally and the idea of RefreshDatabase to keep everyone in sync.

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

--
You received this message because you are subscribed to the Google Groups "chucknorris" group.
To view this discussion on the web visit https://groups.google.com/d/msg/chucknorrisframework/-/ceuoM-fZA6YJ.
To post to this group, send email to chucknorri...@googlegroups.com.
To unsubscribe from this group, send email to chucknorrisframe...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/chucknorrisframework?hl=en.

[Rob Reynolds]

Reading again, is there a concept of a local visual studio build that would allow you to copy that item for testing?

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Rob Reynolds]

Actually on the alternative, you can hook into extension points along the build with uppercut. So it would make the most sense to make a package.post.step and physically delete that file from your code_drop folder. Then you still get the benefit of testing and the safety of not deploying the file accidentally.   http://uppercut.pbworks.com/w/page/9022440/CustomizeUsingExtensionPoints 

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Rob Reynolds]

UppercuT does not integrate with visual studio on purpose. You can let visual studio know about solutionversion.cs/vb to take advantage of versionbuilder but other than that it's not really supported. That said, I'm sure there is a way you can get your template files to build and be used in visual studio, just not something I have experience trying since I get the functionality that I need from looking at it the way described above (extension points).

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Alan Howard]

Also,

• Not everyone has the same sql-server instancename (.\sql2005 <> .) 

You can get around this by using SQL Configuration Manager to set a client alias on each dev workstation, and then use this alias in your dev connection strings. This really just moves the maintenance to another area, but at least makes the different dev environments look the same to Uppercut.

Alan

[Jan Verhaeghe]

>>> On Mon, Apr 2, 2012 at 9:55 AM, Rob Reynolds <ferven...@gmail.com> wrote:
>>>>
>>>> What about using something like SQLite for automated testing? Putting on
>>>> my unit testing principles hat for a second...

Don't worry about the unit testing principles, I'm wearing the
three-piece suit at the moment ;-)

We have separated our tests into real unittests (fast, no config,
possibly mutlithreaded, ...) and NUnit-based integration tests
(NHibernate mapping, NUnitForms, ...) .
Using the UppercuT assembly naming convention only the "real"
unittests get run during compile.bat.

Our developers are only required to run the compile.bat step before
committing, however the other tests still need to be developed and run
locally sometimes...

>> On Mon, Apr 2, 2012 at 9:57 AM, Rob Reynolds <ferven...@gmail.com> wrote:
>>>
>>> Reading again, is there a concept of a local visual studio build that
>>> would allow you to copy that item for testing?

I'm not sure what you mean with a "local visual studio build". Our
solutions only contains regular vb/C# projects without custom MSBuild
build events.

> On Mon, Apr 2, 2012 at 9:59 AM, Rob Reynolds <ferven...@gmail.com> wrote:
>>
>> Actually on the alternative, you can hook into extension points along the
>> build with uppercut. So it would make the most sense to make a
>> package.post.step and physically delete that file from your code_drop
>> folder. Then you still get the benefit of testing and the safety of not
>> deploying the file accidentally.
>> http://uppercut.pbworks.com/w/page/9022440/CustomizeUsingExtensionPoints

This is what I'll be looking into in combination with Alan Howard's suggestion.

I'll add a hibernate.cfg.xml file to the project pointing to some
local common development alias, this way everyone can choose the
instance name freely as long as they make sure the alias is
configured.
And during packaging I'll remove all the files that are templated ...

Greetings,

Jan

[Jan V]

Cool, didn't know about this.  Problem solved :) Thx for the pointer!

Op maandag 2 april 2012 23:29:19 UTC+2 schreef nzduck het volgende:

[Rob Reynolds]

By local visual studio build, I was really only talking about Ctrl+Shift+B in visual studio. The build you get when you build in visual studio. Sorry for the confusion there...bad wording on my part.

--
You received this message because you are subscribed to the Google Groups "chucknorris" group.

[Rob Reynolds]

I didn't know about this either. Very awesome.

--
You received this message because you are subscribed to the Google Groups "chucknorris" group.

To view this discussion on the web visit https://groups.google.com/d/msg/chucknorrisframework/-/cOICziQPFZEJ.

[Rob Reynolds]

Adding this note to RoundhousE's wiki:  https://github.com/chucknorris/roundhouse/wiki/Roundhouserefreshdatabasefnh#wiki-notes 

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Rob Reynolds]

I added an image that shows a working example for me using Named Pipes (less configuration that way - at least I think it's less configuration :) ).

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[Alan Howard]

Oh sorry. I should have thought about doing that as well.