|
| 1 | +// Copyright (c) Microsoft Corporation. |
| 2 | +// Licensed under the MIT License. |
| 3 | + |
| 4 | +using RulesEngine.Models; |
| 5 | +using System; |
| 6 | +using System.Diagnostics.CodeAnalysis; |
| 7 | +using System.Threading.Tasks; |
| 8 | +using Xunit; |
| 9 | + |
| 10 | +namespace RulesEngine.UnitTest |
| 11 | +{ |
| 12 | + [ExcludeFromCodeCoverage] |
| 13 | + public class Issue692Test |
| 14 | + { |
| 15 | + public class WithNullableDate |
| 16 | + { |
| 17 | + public DateTime? Dt { get; set; } |
| 18 | + } |
| 19 | + |
| 20 | + // The reporter says: when comparing a null DateTime against a set DateTime, BOTH |
| 21 | + // `<` and `>` return false (whereas in 5.0.3 and earlier null was treated as |
| 22 | + // "less than" any set datetime). |
| 23 | + // |
| 24 | + // Behavior of standard .NET nullable DateTime semantics: |
| 25 | + // null < someDateTime → false (Nullable<T> comparisons return false when either operand is null) |
| 26 | + // null > someDateTime → false |
| 27 | + // This is the SAME as standard C# semantics — Nullable<T> comparisons are tri-valued |
| 28 | + // and false-when-null is the documented behavior. There is no "null is less than" rule |
| 29 | + // in .NET; the reporter's previous behavior was either via Newtonsoft.Json string-typing |
| 30 | + // (null treated as empty / default DateTime) or via a Dynamic.Core quirk. |
| 31 | + // |
| 32 | + // These tests document the current behavior so we don't accidentally regress. |
| 33 | + [Fact] |
| 34 | + public async Task NullableDateTime_LessThan_NullReturnsFalse() |
| 35 | + { |
| 36 | + var workflow = new Workflow |
| 37 | + { |
| 38 | + WorkflowName = "wf", |
| 39 | + Rules = new[] { new Rule { RuleName = "R", Expression = "input1.Dt < DateTime.Now" } } |
| 40 | + }; |
| 41 | + var engine = new RulesEngine(new[] { workflow }, |
| 42 | + new ReSettings { CustomTypes = new[] { typeof(DateTime) } }); |
| 43 | + var results = await engine.ExecuteAllRulesAsync( |
| 44 | + "wf", new[] { RuleParameter.Create("input1", new WithNullableDate { Dt = null }) }); |
| 45 | + |
| 46 | + Assert.False(results[0].IsSuccess); |
| 47 | + } |
| 48 | + |
| 49 | + [Fact] |
| 50 | + public async Task NullableDateTime_GreaterThan_NullReturnsFalse() |
| 51 | + { |
| 52 | + var workflow = new Workflow |
| 53 | + { |
| 54 | + WorkflowName = "wf", |
| 55 | + Rules = new[] { new Rule { RuleName = "R", Expression = "input1.Dt > DateTime.Now" } } |
| 56 | + }; |
| 57 | + var engine = new RulesEngine(new[] { workflow }, |
| 58 | + new ReSettings { CustomTypes = new[] { typeof(DateTime) } }); |
| 59 | + var results = await engine.ExecuteAllRulesAsync( |
| 60 | + "wf", new[] { RuleParameter.Create("input1", new WithNullableDate { Dt = null }) }); |
| 61 | + |
| 62 | + Assert.False(results[0].IsSuccess); |
| 63 | + } |
| 64 | + |
| 65 | + // The canonical workaround for users who DO want null-aware semantics: check HasValue |
| 66 | + // explicitly. This is also the standard C# pattern. |
| 67 | + [Fact] |
| 68 | + public async Task NullableDateTime_ExplicitHasValueCheck_WorksAsExpected() |
| 69 | + { |
| 70 | + var workflow = new Workflow |
| 71 | + { |
| 72 | + WorkflowName = "wf", |
| 73 | + Rules = new[] { |
| 74 | + new Rule { RuleName = "TreatNullAsLess", |
| 75 | + Expression = "!input1.Dt.HasValue || input1.Dt < DateTime.Now" } |
| 76 | + } |
| 77 | + }; |
| 78 | + var engine = new RulesEngine(new[] { workflow }, |
| 79 | + new ReSettings { CustomTypes = new[] { typeof(DateTime) } }); |
| 80 | + |
| 81 | + var withNull = await engine.ExecuteAllRulesAsync( |
| 82 | + "wf", new[] { RuleParameter.Create("input1", new WithNullableDate { Dt = null }) }); |
| 83 | + Assert.True(withNull[0].IsSuccess); |
| 84 | + |
| 85 | + var withValue = await engine.ExecuteAllRulesAsync( |
| 86 | + "wf", new[] { RuleParameter.Create("input1", new WithNullableDate { Dt = DateTime.Now.AddDays(-1) }) }); |
| 87 | + Assert.True(withValue[0].IsSuccess); |
| 88 | + } |
| 89 | + } |
| 90 | +} |
0 commit comments