I have created a unit test in a separate project. I am trying to change a filepath I have as a setting in the main project. I access the path as My.Settings.FooBarPath. I can't figure out how to change it in my unit test. How do I access the settings in my main project from the unit test project and how do I change the values?
I have read this post: Modifying application settings in unit tests
The second answer seemed to be the most useful but I couldn't quite seem to get it to work for my unit tests.
One way is to modify the settings.xml file manually. It's a bit convoluted, but this tutorial might help for saving and loading text files into your app (of course you'd do it without a UI) - https://www.youtube.com/watch?v=O3nSXaD2J9Q
Another option is to start up your other program with Shell() and have a command line argument for the setting to change and what to change it to.
The question asked was for VB.Net while the answer given in Modifying application settings in unit tests is for C#. As I had the same question for VB.Net I thought I'd give a VB.Net version of the answer here. Based on the C# answer I got this to work in my project (using Visual Studio 2013) with the following:
The test project should be correctly set up as a unit test for the application under test ("Create and run unit tests" should help in setting it up correctly)
using the fully qualified namespace of the application under test myprojects_namespace.My.settings
will give you full (intellisense powered) access to the user settings of the application under test.
After that you can read / write to the user settings as you would normally do.
e.g.
myprojects_namespace.My.settings.someProperty = "somevalue"
Assert.AreEqual("somevalue", myprojects_namespace.My.settings.someProperty)
P.S.: I didn't need to add anything in my AssemblyInfo.vb file. There is no reference to System.Runtime.CompilerServices.InternalsVisibleTo as this seems to already have been handled by setting up the unit test project correctly for the application under test.
Related
Currently, I define the following function in the REPL at the start of a coding session:
(defn rt []
(let [tns 'my.namespace-test]
(use tns :reload-all)
(cojure.test/test-ns tns)))
And everytime I make a change I rerun the tests:
user=>(rt)
That been working moderately well for me. When I remove a test, I have to restart the REPL and redefine the method which is a little annoying. Also I've heard bad rumblings about using the use function like this. So my questions are:
Is using use this way going to cause me a problem down the line?
Is there a more idiomatic workflow than what I'm currently doing?
most people run
lein test
form a different terminal. Which guarantees that what is in the files is what is tested not what is in your memory. Using reload-all can lead to false passes if you have changed a function name and are still calling the old name somewhere.
calling use like that is not a problem in it's self, it just constrains you to not have any name conflicts if you use more namespaces in your tests. So long as you have one, it's ok.
using lein lets you specify unit and integration tests and easily run them in groups using the test-selectors feature.
I also run tests in my REPL. I like doing this because I have more control over the tests and it's faster due to the JVM already running. However, like you said, it's easy to get in trouble. In order to clean things up, I suggest taking a look at tools.namespace.
In particular, you can use clojure.tools.namespace.repl/refresh to reload files that have changed in your live REPL. There's alsorefresh-all to reload all the files on the classpath.
I add tools.namespace to my :dev profile in my ~/.lein/profiles.clj so that I have it there for every project. Then when you run lein repl, it will be included on the classpath, but it wont leak into your project's proper dependencies.
Another thing I'll do when I'm working on a test is to require it into my REPL and run it manually. A test is just a no-argument function, so you can invoke them as such.
I am so far impressed with lein-midje
$ lein midje :autotest
Starts a clojure process watching src and test files, reloads the associated namespaces and runs the tests relevant to the changed file (tracking dependencies). I use it with VimShell to open a split buffer in vim and have both the source and the test file open as well. I write a change to either one and the (relevant) tests are executed in the split pane.
I'm trying out Xamarin (on Mac OS X) to do some cross-platform (Mac, iOS, Android) development in Mono. I've created a "Point" class inside a "Filament" namespace, and now I'm trying to add unit tests.
There appear to be two approaches to unit testing in the Mono world: NUnit and NUnitLite. I've tried both (in the latter case, following this tutorial), with the same result, which is this:
In my unit test project, I add a link to the Point.cs file (by right-clicking the project, using 'Add...', selecting the file, and then choosing the "Add as Link" option). In my unit test file (PointTest.cs), I add "using Filament;" to the top of the file. But despite the fact that I can now use the Point class, and it successfully compiles, Intellisense seems completely oblivious to it -- every time I start to type "Point" it extends this to "PointTest", and when I doggedly change it back to Point, it draws it in red like an error.
In fact, the same trouble happened on my "using" line; I typed "using Filament" and it changed this to "using FilamentTestsiOS" (the namespace of my unit test project).
This is driving me nuts... but as a complete noob to Mono, Xamarin, NUnit, and NUnitLite, I'm sure I'm doing something stupid.
What's the correct way to set up a C#/Mono unit test, so that both intellisense and the compiler will recognize the classes for which I'm writing tests?
I have a simple question. Coming from a java background and having worked extensively with eclipse, netbeans or any other java IDE, is quite nice to have the possibility to add a main method to a class and execute it within the IDE, with just a click, and see the output.
I was looking for the same possibility within xcode4/objective-c but I couldn't find a way. From time to time, I like testing small piece of software, without compiling and running the whole project.
As I am still "thinking" in Java, could you suggest the proper way to achieve this with xcode4 from an "objective-c developer point of view" ?
thanks
There's not really a lightweight way to do this, but you have two options that I can think of depending on whether you want to keep the harness code you've written.
If you do, then you'd need to make a new target in your project for each class you drive with a harness, and have that target build just the class you are driving and a simple file with just the main code to drive that class.
If you don't, then you could make a target with a main, and each time you want to drive a different class, change which files are built, change the code in main, and rebuild.
This is assuming that you want to avoid both running and compiling the rest of your code. If you don't mind compiling everything, you could have one test-harness target that builds all of your classes, and either change main on the fly, or use #ifdefs or a runtime argument to decide which helper code to run.
For our webapp testing environment we're currently using watin with a bunch of unit tests, and we're looking to move to selenium and use more frameworks.
We're currently looking at Selenium2 + Gallio + Xunit.net,
However one of the things we're really looking to get around is compiled testcases. Ideally we want testcases that can be edited in VS with intellisense, but don't require re-compilling the assembly every single time we make a small change,
Are there any frameworks likely to help with this issue?
Are there any nice UI tools to help manage massive ammount of testcases?
Ideally we want the testcase writing process to be simple so that more testers can aid in writing them.
cheers
You can write them in a language like ruby (e.g., IronRuby) or python which doesnt have an explicit compile step of such a manner.
If you're using a compiled a compiled language, it needs to be compiled. Make the assemblies a reasonable size and a quick Shift F6 (I rewire it to shift Ins) will compile your current project. (Shift Ctrl-B will typically do lots of redundant stuff). Then get NUnit to auto-re-run the tests when it detects the assembly change (or go vote on http://xunit.codeplex.com/workitem/8832 and get it into the xunit GUI runner).
You may also find that CR, R# and/or TD.NET have stuff to offer you in speeding up your flow. e.g., I believe CR detects which tests have changed and does stuff around that (at the moment it doesnt support the more advanced xunit.net testing styles so I dont use it day to day)
You wont get around compiling test frameworks if you add new tests..
However there are a few possibilities.
First:
You could develop a native language like i did in xml or similar format. It would look something like this:
[code]
action name="OpenProfile"
parameter name="Username" value="TestUser"
[/code]
After you have this your could simply take an interpreter and serialize this xml into an object. Then with reflection you could call the appropriate function in the corresponding class. After you have a lot of actions implemented of course perfectly moduled and carefully designed structure ( like every page has its own object and a base object that every page inherits from ), you will be able to add xml based tests on your own without the need of rebuilding the framework it self.
You see you have actions like, login, go to profile, go to edit profile, change password, save, check email etcetc. Then you could have tests like: login change password, login edit profile username... and so on and so fort. And you only would be creating new xmls.
You could look for frameworks supporting similar behavior and there are a few out there. The best of them are cucumber and fitnesse. These all support high level test case writing and low level functionality building.
So basically once you have your framework ready all your have to do is writing tests.
Hope that helped.
Gergely.
I have a windows form application in which I'm attempting to utilize a plugin (class library). In the code I have it load the assembly from a dll file, which means I have not been able to debug. Furthermore I have not found out how to compile the library so I've had to use the debuged dll version for testing. I've run into a bug in which I create a new object and send that data through an interface to the plugin in an attempt to retrieve a blank slate group box from the plugin. However instead of reading the parameter as a new object i managed to step through the code once (don't ask me how, I don't know and I haven't been able to repeat it) and it appeared that the code was registering the parameter as "nothing" thus why I received a null reference error in the main program.
Is there a better way to debug this mechanism and find out where the problem is? Any ideas on what the problem could be. As I read over this is seems somewhat vague and I'm not sure how to describe it, but I'm willing to host a connect now meeting if anyone is willing to look at what is going on and I'm not making myself understood very well.
I'm not sure if I follow exactly what you're doing but I usually find that the best way to debug a class library is by in the solution for the class library I add a new project, either a WinForms one or a Console one, I then set this new project as the start up project and add a reference to the Class Library project (via the Project tab in the Add Reference dialog).
You'll then be able to call the methods in the class library from the other project and you can put breakpoints anywhere to see what's really going on easily.
Ok, so the problem was that any time you edit the class library you have to compile (and the only way I know how is debugging, I can't find a compile button and the publish button doesn't work and building doesn't appear to make a dll). But anyways you have to compile, transfer the file so you are reading the most recent one. If you edit the code during runtime it does NOT update the dll in use...which was my problem.