Page 1 of 1

Using Ranorex with Git...

Posted: Wed Nov 02, 2016 5:24 pm
by mto
Hello all,

I am currently using the git repo for my Ranorex project. Internally, we use Gerrit for code reviews.
The big problem is that all the project files are commiited to the repo. This makes code review difficult to do because we need only do that for "UserCode.cs" files. (see attachment)

My question is: it is possible to ignore all automatically generated files?
- like ".cs" automatically generated ?
- like ".rximg"?
- like ".rxtmg"?
- like ".csproj"?
- like ".rxtst"?
- ...etc

What is the impact if i add all these files in ".gitignore"? can you please give me an example of your .gitignore file?

Thank you for your help.

MTO

Re: Using Ranorex with Git...

Posted: Wed Nov 02, 2016 7:54 pm
by krstcs
Do not ignore generated files. These are very important and should be part of your project in whatever versioning system you are using. Ranorex cannot work with (or recreate) the tests without these files.

There is no need to do code reviews on these files though, so I don't understand what your issue is? Just don't do manual reviews on them, and if you need to exclude them then you should do that through Gerrit, if that is possible (I don't use it).


In my opinion, doing formal code reviews on Ranorex test code is a waste of time for several reasons:

1. Your test modules should not be big enough to need formal review. Keep your modules as small as possible, only doing one thing. For example, if you need to click an OK button, your module should do ONLY that, click the OK button. If you need to enter a username, your module should only click in the field, enter the username, and validate that the value is correct afterwards (no different than a user clicking the field, typing in the username, and then visually checking to make sure it's correct).

2. If you make your modules too big, they become harder to use (and re-use) and maintain.

3. If you are making big modules then it also means you may have issues with non-technical people understanding what your tests are doing.

4. You may not be using the already-built Ranorex mechanisms that you could be using because they save time and make it very hard to mess up the code. Don't re-invent the wheel.