We just encountered something that seemed kind of odd, so I wanted to pass
it by the list to see if it could be a possible feature.
In Benchee we want to accept either a module or a function as an argument
to a function. We'll have different behavior depending on the type there
(since we're
Howdy,
So I'm writing a bunch of tests today that involve checking the output of a
function against some known good values and asserting that they're similar
enough. These are all lists, and the code I'm using for that is this:
defp assert_similar(list_1, list_2) do
[list_1, list_2]
It's already happened to me a couple times this week where I'll have a
skipped test somewhere and forget to unskip it because when we have skipped
tests in our suites it shows all green in the output. I'm sure I'm not the
only one this happens to ;)
I propose that when we have skipped tests in
There has been lots of discussion around making things private (like
private modules, what to show in documentation for private functions that
aren't defined with defp, etc.). Currently there is an implicit rule that
if something is undocumented then it is private and shouldn't be used, so
As part of debugging an issue in Benchee recently, we needed to look at
BEAM instructions for some code to see what exactly was being generated on
OTP 20 and OTP 21. I also know of several other people in the community
that need to look at the BEAM instructions from time to time, either for
ector of R
>
> On Mon, Aug 6, 2018 at 9:48 AM, Devon Estes > wrote:
>
>> As part of debugging an issue in Benchee recently, we needed to look at
>> BEAM instructions for some code to see what exactly was being generated on
>> OTP 20 and OTP 21. I also know of several o
Currently, if I want to run only a single test by line number, I can easily
do:
mix test test/potion_web/plugs/persist_request_plug_test.exs:92
This is parsed in ExUnit as:
Including tags: [line: "92"]
Excluding tags: [:test]
But if I want to only run two tests in a file, I need
we don't need to support multiple files, then I
>> would do:
>>
>> mix test test/potion_web/plugs/persist_request_plug_test.exs:92:94:102
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R
>>
What about Function.identity/0, that returns an anonymous identify function?
def identity(), do: &(&1)
So usage would look like:
Enum.map(list, Function.identity())
That (to me) works just as well as Function.identity/1, and keeps with the
convention of functions in the Function module
I'm not sure if there is a reason for not having done this in the past but
I couldn't find anything in the mailing list about it already.
There is essentially a behaviour that's defined in the documentation for
ExUnit.Formatter, but it's not actually enforced by defining a @behaviour
for
I was playing around with multi-language umbrella applications yesterday,
it's great that mix knows how to compile applications managed by rebar3, I
found myself wishing that I could similarly run my tests from the root of
the umbrella with `mix test` in the same way. I thought about it a
I think doctests are extremely helpful and powerful since they encourage
developers to write testable, accurate documentation for their code. But
the lack of some of the niceties that exist in ExUnit might make it less
likely for developers to choose doctests instead of ExUnit tests, so I've
I have some Doctests that emit logs, and I don't want that stuff clogging
up my terminal, so I would like to be able to tag those with `:capture_log`
like I can with other tests.
What do folks think about something like this, which would apply that tag
to all doctests generated with that call
to a list
before calling take_random/2.
Thoughts?
--
_
Devon Estes
+49 176 2356 4717
www.devonestes.com
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails fro
omatically remove those is arguably the only reason for
>> tight integration with exunit. As you can see the implementation is
>> currently fairly generic.
>>
>> I focused on the ex_unit case but a more general utility is interesting
>> too.
>>
>> About @tag tmp
rom this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/066A99E3-B470-44C3-9632-F52E97AB8791%40wojtekmach.pl
> .
>
--
_
Devon Estes
+4
; To unsubscribe from this group and stop receiving emails from it, send an
>> email to elixir-lang-core+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/38192124-1f41-407c-966e-82f223db3719n%40go
ferent arities: 0, 1, and 2.
>>
>> On 26 Dec 2020, at 09:43, Devon Estes wrote:
>>
>>
>>
>> This seems like a source of potentially confusing issues to me, as
>> mentioned earlier. I do admit that this would be a very rare occurrence,
>> but in general i
;https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQvmO_sO-QuqbxAbaOZc_Y8PVx7t64PFWU40YSk4ttordg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To
; provided); repeating suite or tests can be done by wrapping the `describe`
> or `test` blocks in loops.
>
> -a
>
> On Wed, Oct 21, 2020 at 10:54 AM Devon Estes
> wrote:
>
>> Making tools that folks can easily misuse does indeed damage the greater
>> community, i
Founder of Difference Engineers
> 202-643-2263
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+
ioned, structs are a really cool solution because they provide
>
> rigidity, defaults, and the assertive map access syntax with ".". Creating
> a
>
> struct for every function that accepts options feels like a bit much
> though.
>
>
>
> Taking everything a
n getting no
> feedback at all.
>
> On Wed, Dec 30, 2020 at 5:36 PM Devon Estes
> wrote:
>
>> I don’t think the issue is with fetching the values, as we already have
>> Keyword.fetch!/2. The root cause of the issue is that there is connascence
>> of name
23 matches
Mail list logo
