Failing unit tests (Examine.Test.Examine.Lucene.Search.FluentApiTests.Sort_Result_By_Double_Fields)

[nikcio]

When running the unit tests locally I've experienced that two unit tests keep failing:

Failed Sort_Result_By_Double_Fields("fulltext",Double) [1 s]
  Error Message:
     Expected: 2.6000000000000001d
  But was:  5.0d

  Stack Trace:
     at Examine.Test.Examine.Lucene.Search.FluentApiTests.Sort_Result_By_Double_Fields(String fieldType, SortType sortType) in C:\Vertica\Github\misc\Examine\src\Examine.Test\Examine.Lucene\Search\FluentApiTests.cs:line 1385

  Failed Sort_Result_By_Double_Fields("fulltextsortable",Double) [1 s]
  Error Message:
     Expected: 2.6000000000000001d
  But was:  5.0d

  Stack Trace:
     at Examine.Test.Examine.Lucene.Search.FluentApiTests.Sort_Result_By_Double_Fields(String fieldType, SortType sortType) in C:\Vertica\Github\misc\Examine\src\Examine.Test\Examine.Lucene\Search\FluentApiTests.cs:line 1385

The weird thing is that they don't seem to be failing in the GitHub workflow. I see the two tests fail both in Visual Studio 2022 and when using dotnet test

Source code:

Examine/src/Examine.Test/Examine.Lucene/Search/FluentApiTests.cs

Lines 1313 to 1369 in 9a26cec

	[TestCase(FieldDefinitionTypes.Double, SortType.Double)]
	//[TestCase(FieldDefinitionTypes.Double, SortType.String)] // This differs from Lucene 3.x, if string is specified it will still sort like as string
	[TestCase(FieldDefinitionTypes.FullText, SortType.Double)]
	[TestCase(FieldDefinitionTypes.FullText, SortType.String)]
	[TestCase(FieldDefinitionTypes.FullTextSortable, SortType.Double)]
	[TestCase(FieldDefinitionTypes.FullTextSortable, SortType.String)]
	public void Sort_Result_By_Double_Fields(string fieldType, SortType sortType)
	{
	// See: https://github.com/Shazwazza/Examine/issues/242
	var analyzer = new StandardAnalyzer(LuceneInfo.CurrentVersion);
	using (var luceneDir = new RandomIdRAMDirectory())
	using (var indexer = GetTestIndex(
	luceneDir,
	analyzer,
	new FieldDefinitionCollection(
	new FieldDefinition("field1", fieldType))))
	{
	indexer.IndexItems(new[]
	{
	ValueSet.FromObject(1.ToString(), "content", new { field1 = 5.0 }),
	ValueSet.FromObject(2.ToString(), "content", new { field1 = 4.9 }),
	ValueSet.FromObject(3.ToString(), "content", new { field1 = 4.5 }),
	ValueSet.FromObject(4.ToString(), "content", new { field1 = 3.9 }),
	ValueSet.FromObject(5.ToString(), "content", new { field1 = 3.8 }),
	ValueSet.FromObject(6.ToString(), "content", new { field1 = 2.6 }),
	});
	var searcher = indexer.Searcher;
	var sc = searcher.CreateQuery("content");
	var sc1 = sc.All()
	.OrderBy(new SortableField("field1", sortType));
	sc = searcher.CreateQuery("content");
	var sc2 = sc.All()
	.OrderByDescending(new SortableField("field1", sortType));
	var results1 = sc1.Execute().ToList();
	var results2 = sc2.Execute().ToList();
	Assert.AreEqual(2.6, double.Parse(results1[0].Values["field1"]));
	Assert.AreEqual(3.8, double.Parse(results1[1].Values["field1"]));
	Assert.AreEqual(3.9, double.Parse(results1[2].Values["field1"]));
	Assert.AreEqual(4.5, double.Parse(results1[3].Values["field1"]));
	Assert.AreEqual(4.9, double.Parse(results1[4].Values["field1"]));
	Assert.AreEqual(5.0, double.Parse(results1[5].Values["field1"]));
	Assert.AreEqual(2.6, double.Parse(results2[5].Values["field1"]));
	Assert.AreEqual(3.8, double.Parse(results2[4].Values["field1"]));
	Assert.AreEqual(3.9, double.Parse(results2[3].Values["field1"]));
	Assert.AreEqual(4.5, double.Parse(results2[2].Values["field1"]));
	Assert.AreEqual(4.9, double.Parse(results2[1].Values["field1"]));
	Assert.AreEqual(5.0, double.Parse(results2[0].Values["field1"]));
	}
	}

Example in GitHub actions: https://github.com/Shazwazza/Examine/actions/runs/3297631605/jobs/5438680589#step:9:5658

[nzdev]

@nikcio The answer here is strict equality does not work well for comparing doubles. Some tolerance needs to be made. See https://stackoverflow.com/questions/8825956/assert-areequal-with-system-double-getting-really-confusing.

[nikcio]

@nzdev That actually makes a ton of sense

[nzdev]

I'm not sure. On closer inspection, the values are way off