When running test suites inside Selenium IDE, you can set the ‘Base URL‘, which is basically the domain part of the site under test. If you want to be able to run the same test suite against various environments, such as ‘test’ or ‘stage’, you obviously want to run with different base URLs. However, it’s not that obvious how you accomplish this, and it’s not well documented either.
What may happen if you try to just change the base URL is that the first test case in your suite runs against the new setting while the rest run against previous settings. The cause of this lies in the fact that each test case can have a hidden base URL, as shown below!
What you want to do is to simply remove the complete line with the link element. Then Selenium will use whatever you write in the ‘Base URL‘ field when running the test suite. Handy eh?
Imagine that you’ve been working for a while on a particular feature, and that the code is versioned under Subversion or some other VCS. You’ve made changes in a couple of files but you’re not yet ready to commit. Then suddenly you need to quickly switch to another task because someone in your team needs a bug fixed. Or perhaps, you need to fully switch focus to another feature, because unfortunately someone re-prioritized in the middle of your iteration! This could get messy, especially if the features intersect code-wise. I bet you have (at least some time during your career) copied the modified files to a location outside your project for storage, and then merged them manually when the time came to start working on the feature again (it’s OK, noone can see you nod :-)).
A decent way of solving this situation in IntelliJ, is to use the neat little feature Shelve Changes. It works sort of like an extra local layer of VCS. Just go to the Changes tab, right-click your modified files and then Shelve the Changes. This puts them in a shelf on the file system, and removes them from the list of modified files. Now you can continue working as usual, committing and updating your local repo until you want to Unshelve the Changes. Should there then be any conflicts, IntelliJ provides a merge tool.
Obviously, this is even neater if you start using Change Lists properly. Then you have all the modified files grouped under the change list, and you can then easily Shelve the entire change list.
Finally, a word of warning since this type of local versioning is prone to all the usual problems with having local copies. It’s best used in rare cases when options are limited, and you are prepared to potentially losing all the changes due to a system failure.