This was not an easy one… I was trying to run a unit test with MSTest but I was always getting the following error:
Unit Test Adapter threw exception: Type is not resolved for member ‘XXX,XXX Version=184.108.40.206, Culture=neutral, PublicKeyToken=null’
As usual in such case – a message which does not really say what’s wrong. I googled the problem but there was not much about it on the web. The best resource I found was post titled VSTS Unit Test ‘Type is not resolved’ exception. It describes how VSTestHost process runs the test and explains what the possible problem might be in this case.
The author suggests that data required for test (e.g. a dll file) is not found in base directory for AppDomain (i.e. unit test ‘Out’ directory) because it’s already switched back to directory that holds VSTestHost.exe. There are two links to MSDN given where Microsoft admits this is a known bug and provides a hack to work around the problem – supply VSTestHost with copies of required artifacts (again, this is described in details in above mentioned post).
Unfortunately that didn’t work with my case. I’ve found the root cause though…
Continue reading ‘MSTest: Unit Test Adapter threw exception: Type is not resolved for member XXX’
Visual Studio provides solid support for unit testing. One of the features are VSMDI files – test meta data file. The file is not much readable but Visual Studio comes with easy to use GUI for managing tests (grouping them in test lists, filtering, etc.).
All in all, VSMDI files are really helpful but…
- After a while there are several VSMDI files (MySolutionName1.vsmdi, MySolutionName2.vsmdi, MySolutionName3.vsmdi, …) in your project although only one is in use (and therefore added to source control). This is a known bug discovered in Visual Studio 2005. More information can be found there.
- Painful merging. Merging can be smooth or really painful. It is the latter with VSMDI. Sorry, with VSMDI there’s no such thing like merging. If you discover someone else has changed and checked in VSMDI file (conflict), just replace your local changes with server version and repeat your changes.
The reason for the mess here is each test is given ID which is a GUID which tends to change once in a while.
- Not runnable tests. This doesn’t happen too often but I’ve experienced it several times already. When you try to run some tests you are told they are not runnable because there are multiple tests with the same ID (again, IDs…) – see below. Of course you haven’t played with IDs…
At least this is an easy one (but not when you see that for the first time). Just refresh the whole test list view – select List of Tests in Test List Editor window and click refresh.
Ok, so that’s my list. Any points to add here?
By definition a load test is supposed to simulate many users accessing a server at the same time. It consists of series of iterations, which can be either Web tests or unit tests. Each operation is repeated the defined number of times for each virtual user.
A load test completes with status ‘Completed’. If one needs to learn more details on the run, they should open the result file (trx) and read the statistics. Now, in real world something can go wrong with either the infrastructure or one of the system components. Let’s say that one of the element in a long Web test fails for a reason. In such case you would rather not wasting time analyzing the result of the test to find it out only ten, but write it off automatically.
Continue reading ‘How to abort load test when its scenario fails?’
It’s a fact that coded web test methods give more flexibility to the developer, i.e. common code reuse. So let’s create a coded web test in whose
GetRequestEnumerator() method you want to call a common method which tests some other requests. Let’s make it look as
GetCommonRequests() in the example below:
public class AWebTest : WebTest
private IEnumerator<WebTestRequest> GetCommonRequests()
WebTestRequest req1 = new WebTestRequest("http://google.com");
yield return req1;
WebTestRequest req2 = new WebTestRequest("http://google.com");
yield return req2;
public override IEnumerator<WebTestRequest> GetRequestEnumerator()
WebTestRequest req = new WebTestRequest("http://google.com");
yield return req;
You would expect to see three requests in the test result. You will see only one though…
Continue reading ‘How to invoke a common coded web test method from GetRequestEnumerator()?’
It’s not really possible to fail a load test because by default it always ends with status ‘Completed’. Because of that anytime a load test completes one musts analyze the results – if performance stayed at the acceptable level. So, despite being a powerful tool, load tests require human attention, which makes the whole testing process less automate.
Continue reading ‘Is it possible to fail a load test?’
A coded web test, as opposed to a basic web test, brings more flexibility to the developer: conditioning, looping, code re-usage, etc. If you haven’t created one yet, you can follow an instruction on MSDN.
Now, because a coded web test can have some logic inside, it makes sense to add logging so that there’s a trace on what’s going on while it executes.
Continue reading ‘How to quickly add logging to a coded web test?’
I wanted to change a load test so that it works similar to what Gabriel Szlechtman described in his blog. Additionally, I followed MSDN instruction on how to create a Load Test Plug-In.
So I created a new project with a plug-in class, added a reference to it from load test project and wanted to hook the plug-in with the test. However, when I was doing the last step I was getting the following error:
The fix is quite simple. When I added a new class for the plug-in, it was defined without the access modifier (and therefore it was
internal), which made the class accessible from other classes only in the same assembly. Adding
public access modifier for the plug-in class solved the problem.
When I ran a load test on my environment (Visual Studio TS 2008) for the first time I got the following error:
Error occurred running test. XXX could not access the result repository: Invalid object name ‘LoadTestRun’
The reason for that was I hadn’t had created a database schema for load tests. In order to do it I executed <VS location>\Common7\IDE\loadtestresultsrepository.sql which did all the job.
Please refer to msdn for more information.