assert

I notice Debug.Assert does not trigger in Metro apps, however, if the project is a traditional one like Console or WinForm, it does trigger. And yes, I am in Debug mode. Is it a setting not properly set in Visual Studio (11 Beta)? Or Debug.Assert is intended to be disabled in metro apps? I know many exceptions are swallowed during the execution of Metro apps, but Debug.Assert is so handy that I can't think of a reason why it should be disabled. It does trigger, look in the Output window. It just doesn't automatically prompt you to ask if you want a debugger break and thus just keeps motoring.

Consider the following code: [Test] public void WidgetTest() { foreach (Widget widget in widgets) { Assert.AreEqual(0, widget.SomeValue); } } If one of the asserts fails, I will get a very unhelpful error message like the one below: 1) Test Failure : WidgetTest.TestSomeValue Expected: 0 But was: 1 at WidgetTest.TestSomeValue() So, the question is, how can I get NUnit to display more useful info, such as the name of the widget, or the iteration of the loop, etc? Even a line number would be more helpful, since this is run in automated manner and I'd like to be able to spot the failing assert

I have never understood what is assert used for, even though I have read plenty examples, they don't really let me know what or why should I use it for. So Instead of asking an example, I'm gonna provide one and let me know if this is the proper usage of assert . // The idea is that the `mode` variable should be 0 or 1, and no other number. switch(mode) { case 0: // do stuff break; case 1: // do other stuff break; default: // assert code? } If this is correct, please let me know how to use it in this case. If this is not how it is supposed to use, please provide an example. Not in this case.

The assert -macro from <cassert> provides a concise way of ensuring that a condition is met. If the argument evaluates to true , it shall not have any further effects. However, can its invocation also be used inside a constant expression in that case? This was dealt with by LWG 2234 , which was brought back to attention after relaxed constraints on constexpr functions had been introduced. Proposed resolution : This wording is relative to N3936. Introduce the following new definition to the existing list in 17.3 [definitions]: constant subexpression [defns.const.subexpr] an expression whose

如果您今天正在编程，那么您很可能听说过单元测试或测试驱动的开发过程。我还没有遇到一个既没有听说过又没有听说过单元测试并不重要的程序员。在随意的讨论中，大多数程序员似乎认为单元测试非常重要。 但是，当我开始使用代码并问“单元测试在哪里？”时，我得到了一个完全不同的故事。我最近在网上问我的程序员朋友为什么不这样做，以及为什么其他程序员不这样做呢？不要编写单元测试。当我问程序员或IT经理同样的问题时，我经常听到的第一答案是：“我没有时间”或类似的问题。通常会出现这样的论点，即使用单元测试编写应用程序要比不使用单元测试编写时间长20％，并且“我们受到时间限制”。 我的建议–当我们尝试解决时间不足的问题时，也许我们可以在娱乐性上做出一些贡献。 在实践中 我正在为一个应用程序设计原型，该应用程序将允许用户输入有关房屋装修项目的信息，然后与朋友共享该项目的材料和工具信息。然后，朋友可以承诺贷款或购买项目中所需的一些材料或工具。基本上是用于家庭装修项目的“登记处”。 测试将在采用Project对象的方法上进行，遍历该项目的工具列表以查看该工具是否已经被承诺，并创建一个未被承诺的工具列表。然后，它将把该列表传递给将查询每个工具当前价格的服务。 原型是用Grails完成的，但是我们将用Java编写此方法： public List<Tool> neededToolList(Project project

Short question, why does Assert.AreEqual(1.0, double.NaN, 1.0) pass? Whereas Assert.AreEqual(1.0, double.NaN) fails. Is it a bug in MSTest (Microsoft.VisualStudio.QualityTools.UnitTestFramework) or am I missing something here? Best regards, Egil. Update: Should probably add, that the reason behind my question is, that I have a bunch of unit tests that unfortunately passed due to the result of some linear algebraic matrix operation being NaN or (+/-)Infinity. The unit tests are fine, but since Assert.AreEqual on doubles with a delta will pass when actual or/and expected are NaN or Infinity, I

I'm using Findbugs and javax.annotation.Nonnull on method parameters. On private methods I usually add an assert line to check for nullness like private void myMethod(@Nonnull String str) { assert str != null .... Latest Netbeans version (7.3rc2) is reporting that the assert check is not necessary (because of the Nonnull annotation). I'm not fully sure this is a Netbeans bug or not. Can the assert line be removed because I specified the @Nonnull annotation ? As far as I understand, the annotation is used only during static analysis while assert is, when enabled, active during execution so the

还记得 .NET Framework 的 ASP.NET WebForm 吗？那个年代如果要在 Web 层做单元测试简直就是灾难啊。.NET Core 吸取教训，在设计上考虑到了可测试性，就连 ASP.NET Core 这种 Web 或 API 应用要做单元测试也是很方便的。其中面向接口和依赖注入在这方面起到了非常重要的作用。 本文就来手把手教你如何用 xUnit 对 ASP.NET Core 应用做单元测试。.NET Core 常用的测试工具还有 NUnit 和 MSTest，我本人习惯用 xUnit 作为测试工具，所以本文用的是 xUnit。 创建示例项目 先用 ASP.NET Core API 模板建一个应用。 模板为我们自动创建了一个 ValuesController，为了方便演示，我们只留其中一个 Get 方法： 1 public class ValuesController : ControllerBase 2 { 3 // GET api/values/5 4 [HttpGet("{id}")] 5 public ActionResult<string> Get(int id) 6 { 7 return "value"; 8 } 9 } 然后再添加一个 xUnit 单元测试项目： 模板自动为我们添加好了 xUnit 引用： 1 <ItemGroup> 2

假设有一个生产者线程，一个消费者线程，生产一个，消费一个。我们来看看怎么实现。 #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <assert.h> int buffer; int count = 0; void put(int value) { assert(count == 0); count = 1; buffer = value; } int get() { assert(count == 1); count = 0; return buffer; } void *producer(void *arg) { printf("producer...\n"); int i; int loops = (int) arg; for (i = 0; i < loops; i++) { put(i); printf("put:%d\n",i); } } void *consumer(void *arg) { printf("consumer...\n"); int i; while(1) { int tmp = get(); printf("%d\n",tmp); } } int main() { printf("begin...\n"); pthread_t p; pthread_create(