Deprecate @test_approx_eq (part of #4615)

[StefanKarpinski]

@test_approx_eq_eps, you're next!

[KristofferC]

Is there a non unicode way to do this?

[ararslan]

@test isapprox(x, y)

[cstjean]

They're not 100% equivalent yet, though. isapprox isn't informative (on 0.5)

julia> @test_approx_eq 2.1 1+1
ERROR: assertion failed: |2.1 - 1 + 1| <= 4.440892098500626e-12
  2.1 = 2.1
  1 + 1 = 2
  difference = 0.10000000000000009 > 4.440892098500626e-12
 in test_approx_eq(::Float64, ::Int64, ::Float64, ::String, ::String) at ./test.jl:863
 in test_approx_eq(::Float64, ::Int64, ::String, ::String) at ./test.jl:873

julia> @test isapprox(2.1, 1+1)
Test Failed
  Expression: isapprox(2.1,1 + 1)
ERROR: There was an error during testing
 in record(::Base.Test.FallbackTestSet, ::Base.Test.Fail) at ./test.jl:397
 in do_test(::Base.Test.Returned, ::Expr) at ./test.jl:281

julia> @test 2.1 ≈ 1+1
Test Failed
  Expression: 2.1 ≈ 1 + 1
   Evaluated: 2.1 isapprox 2
ERROR: There was an error during testing
 in record(::Base.Test.FallbackTestSet, ::Base.Test.Fail) at ./test.jl:397
 in do_test(::Base.Test.Returned, ::Expr) at ./test.jl:281

[tkelman]

could we do this with an eval into the Base.Test module from deprecated.jl so it's in a place where we know we'll be deleting it?

[StefanKarpinski]

Eh, I'd rather just leave it here until we tear out the rest of this stuff.

[ararslan]

Fair point, @cstjean. We could check in @test whether the expression is a call to isapprox, but having to perform that check every time might make things slow and/or be overkill.

[StefanKarpinski]

We display lots of test conditions specially, so that could certainly be arranged for isapprox tests.

[tkelman]

This first paragraph seems fine to leave in. Same with the examples that use isapprox, and the ```@docs line for @inferred

[tkelman]

these 2 were worth keeping (though should be made into doctests if possible)

[StefanKarpinski]

Can you open an issue for it?

[tkelman]

about to get on a plane (aren't you, too?), I have a commit on a misc branch locally to put these back, can go into a PR next time I rearrange branches

[giordano]

@test_approx_eq actually had a nice feature: @test_approx_eq NaN NaN didn't give an error. I know there exists isnan, yet that feature was useful when comparing arrays made by a mixture of finite and NaN elements. When doing tests, it makes sense to treat NaNs as equal to each other.

[StefanKarpinski]

I think I'd prefer to have that as a feature of isapprox than keep this weird extra testing API around.

[giordano]

I just wanted to point out a difference between @test_approx_eq and isapprox, not suggest to bring back the former ;-)

I was testing a custom type and in test/runtests.jl I defined a method for isapprox replacing == with isequal, so I found a solution for my use case and have no problem. I'm going to open an ticket to see if other people are interested in this feature.