我很好奇为什么夹具设置必须是静态的?对于我而言,每个夹具具有共享夹具寿命的实例变量似乎更直观.
是的,这些可以在构造函数中初始化,但是我认为它们超出了测试运行器的控制范围.
什么设计要求或哲学确定设置方法应该是静态的?
我想为下面的课程编写单元测试.
如果名称不是"MyEntity",则mgr应为空白.
负单元测试
使用Manager私有访问器我想将名称更改为"Test",以便mgr应为null.然后将验证mgr值.为了实现这一点,我想显式调用静态构造函数,但是当我使用静态构造函数调用时
Manager_Accessor.name = "Test"
typeof(Manager).TypeInitializer.Invoke(null, null);
Run Code Online (Sandbox Code Playgroud)
name始终设置为"MyEntity"如何将名称设置为"Test"并调用静态构造函数.
public class Manager
{
private static string name= "MyEntity";
private static object mgr;
static Manager()
{
try
{
mgr = CreateMgr(name);
}
catch (Exception ex)
{
mgr=null;
}
}
}
Run Code Online (Sandbox Code Playgroud) 我正在寻找与vstest一起使用的.runsettings文件的文档.有xsd吗?
除了msdn文档中的一些示例文件之外,我似乎找不到多少.
我认为这两个测试的行为应该完全相同,事实上我已经使用MS Test在我的项目中编写了测试,现在却发现它不像NUnit那样尊重预期的消息.
NUnit(失败):
[Test, ExpectedException(typeof(System.FormatException), ExpectedMessage = "blah")]
public void Validate()
{
int.Parse("dfd");
}
Run Code Online (Sandbox Code Playgroud)
MS测试(通过):
[TestMethod, ExpectedException(typeof(System.FormatException), "blah")]
public void Validate()
{
int.Parse("dfd");
}
Run Code Online (Sandbox Code Playgroud)
无论我给ms测试什么消息,它都会通过.
如果消息不正确,有没有办法让ms测试失败?我甚至可以创建自己的异常属性吗?我宁愿不必为发生这种情况的每个测试编写一个try catch块.
我们的团队拥有Visual Studio 2012 Professional许可证(不是Test Professional).我们正在开发一个小型的Web应用程序,我们有真正的单元测试,可以模拟所需的一切,并测试数据层.每类数据层测试都从头开始创建整个数据库,并使用一组准备好的测试数据填充它,因此运行它们需要很长时间.结果,我们不愿意做"全部运行",我们的单元测试(快速)只是很少使用.
我们正在寻找一种低摩擦力的解决方案,它允许我们经常进行2-3次点击(类似于现有的全部运行)的所有快速测试,并在需要时轻松运行所有测试.
我们尝试仅制作快速测试的播放列表.但是我们已经完成了对数据层的编程,因此几乎我们编写的所有新测试都是快速测试,并且将每个测试添加到播放列表都很烦人且容易出错.我们更喜欢一种方法,我们以某种方式将我们不想要的测试标记为"快速运行",并自动运行解决方案中的所有其他测试.请注意,我们不希望将慢性测试永久添加Ignore属性,因为我们仍希望每天至少运行一次.
我注意到今天VS 2015中的一个解决方案发生了变化.似乎为解决方案生成的测试项目使用与同一解决方案中的现有测试项目不同的命名空间.
只有参考的测试项目
Microsoft.VisualStudio.QualityTools.UnitTestFramework
被认为是Visual Studio 2015中的测试项目.
但是现在有一些测试项目引用了
Microsoft.VisualStudio.TestPlatform.TestFramework Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions
这些测试项目可能来自VS 2017 RC.这可以解释不同的命名空间.我没有找到任何关于向后兼容性的文档.
问题是,使用哪个命名空间?因为我们不能同时使用这两个名称空间.两个命名空间之间有什么区别?
VisualStudio 2015能够使用任一参考构建测试项目.仅仅因为生成测试项目而将较新的命名空间切换回较旧的命名空间我认为不够.
c# unit-testing mstest visual-studio-2015 visual-studio-2017
我试图对我创建的可移植类库进行单元测试,并且我想确保它使用与其目标相同的框架子集进行测试.
根据Visual Studio ALM + Team Foundation Server博客,MSTest单元测试框架在Visual Studio 2012 RC中转换为PCL; 但是,我无法创建可移植的类库,然后在VS2012 RTM中引用MSTest框架.
Microsoft.VisualStudio.QualityTools.UnitTestFramework产生未找到引用的构建错误.C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll产生构建警告,说明UnitTestFramework程序集引用了不兼容的mscorlib版本.我确实找到了(感谢早期的答案),有一个项目类型Unit Test Library (Windows Store apps)引用了不同的 MSTest程序集C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0\ExtensionSDKs\MSTestFramework\11.0\References\CommonConfiguration\neutral\Microsoft.VisualStudio.TestPlatform.UnitTestFramework.dll.此项目类型创建一个小的无UI Windows应用程序应用程序...完成清单和所有内容.它也不允许我指定我所针对的框架 - 它似乎仅适用于Windows应用商店应用.
在潜在的错误假设下,我应该使用单元测试程序集测试我的可移植类库项目,该单元测试程序集的目标是与被测试库相同的框架子集...
如何为.NET可移植类库创建单元测试程序集?
(我对其他同样针对PCL的框架持开放态度,我目前还没有意识到MSTest之外的其他解决方案已经考虑到了这一点.)
我有一些测试需要从excel文件中提供外部数据.这些文件包含在测试项目中,在Visual Studio中,我编辑了测试设置文件(Local.testsettings)来部署数据文件.这使它工作正常我VS.
但是,我们也在与TeamCity进行持续集成,而在TeamCity中,这不起作用.我的数据文件不可用于测试.似乎测试是从名为"C:\ TeamCity\buildAgent\temp\buildTmp\ciuser_AS40VS6 2009-12-11 09_40_17\Out"的临时文件夹运行的,并且数据文件不会在那里复制.
我已经尝试将数据文件的构建操作更改为"资源"并将复制到输出目录设置为"始终",但这没有帮助.
有谁知道如何使这项工作?
我正在运行Visual Studio 2010 beta 2和TeamCity 4.5.5,这就是为什么我首先运行MSTest,而不是NUnit ...
之前,我能够在Visual Studio 2013下运行特定项目的单元测试.这最近停止了工作,没有对项目进行重大改变,不幸的是,我不记得它什么时候做了最后一次工作,也没有改变.但是,对项目本身的任何修改都是最小的(一个或两个新方法),并且不涉及任何配置文件更改或类似的频繁报告的问题.我相信Visual Studio(可能是最近的更新)或插件或第三方软件的更改导致了以下问题.
加载项目时,一分钟后,"输出"窗口中的"测试"输出显示:
------发现测试开始------
无法初始化客户端代理:无法连接到测试进程vstest.discoveryengine.x86.exe.
==========发现测试结束:0找到(0:00:59.8853102)==========
类似于以前报告的问题,只是调试停止工作,以管理员身份运行Visual Studio似乎"解决"了这个问题.然而,这只是表明问题可能与访问权限有关.
我发现了一个相关的Microsoft Connect错误报告,该报告还暗示了由第三方应用程序引起的问题.显然vstest.discoveryengine.x86.exe使用命名管道进行通信devenv.exe.另一个应用程序可能会使用该请求,从而导致Visual Studio连接失败.但是,验证哪些命名管道正在使用中,我没有找到任何立即明显的罪魁祸首.我还想象连接可能由于其他原因而失败.
启用日志记录后 devenv.exe,vstest.executionengine.exe和vstest.discoveryengine.exe我发现与在devenv的日志中发现引擎但下列情况除外:
E, 10048, 42, 2014/12/22, 01:47:13.683, 63637924754, devenv.exe, TestRunnerServiceClient: Could not connect to test runner service within the available time 60000. Reason:System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://steven-flip/vstest.discoveryengine/8232 that could accept the message. This is often caused by an incorrect address or SOAP action. See …Run Code Online (Sandbox Code Playgroud)