1st item is not possible in elixir, since you can’t call function with wrong parameters (it won’t compile). By “wrong” I mean too much/too little params.
This leaves us to 2nd item - making sure you handle data correctly. That’s why you mock data, not services.
Btw:
I googled “integration tests are a scam” because that title seemed strange. The title appeared a mistake: Clearing Up the Integrated Tests Scam - The Code Whisperer
I am not talking about a signature ( you even have spec to help with that ) I am talking about calling the contract with params that make no sense. Like wrong values and such.
Really, go watch the video conference. It will help you understand the context of this discussion:
@Egis Dialyzer won’t save you. In fact, if you are using Elixir 1.7.X it will even hurt you, as it doesn’t even work.
Even if ti did work, it wouldn’t matter. Dialyzer can’t understand that a method being called with “foo” should be instead called with “baz”. For Dialyzer, both are strings and the function’s signature is correct, so it passes.
As for property testing, I am not convinced. I am actually reading a book that mentions it ( The Little Elixir and OTP Guidebook ) but the examples are rather contrived and perfected to make sense using property testing. The applications to the real world are … considerably more limited.
Still, this is a discussion for another topic. I don’t think property testing is a good as people say ( feel free to create a new discussion referring me if you want to try and convince me) but I am still studying it’s potential applications.
This discussion is about TDD and good resources for those who value it.
Please do not tell it like this, as dialyzer works with 1.7.x if the OTP versions match. This is not an issue of dialyzer or elixir, this is an issue of installing the correct things in the correct versions.
This sounds to me as if the types haven’t specified correctly.
Sad. You should give it a go. For algorithms that have well defined properties this is a nice thing.
Eg. list == list |> reverse |> reverse or a + b == b + a or len(a++b) == len(a) + len(b). Having those is really nice. Of course it requires a different set of thinking than example based testing.
No it doesn’t: https://stackoverflow.com/questions/53427886/which-version-of-elixir-otp-erlang-can-we-use-with-dialyzer
Dialyzer checks types. Doesn’t check values. I could have a function add return 1+1=3 and it would pass. Why? both are numbers, return a number and the function takes the correct number of parameters. It is still wrong. Dialyzer doesn’t know any better because it doesn’t check values. That’s the job of TDD. To say that Dialyzer can replace TDD is just flat out wrong. It can help, sure, but never replace.
Yo are correct. However I found two main issues:
I am not giving up on PT, not yet. I want to delve deeper into it, however at this point in time, I am still not convinced 
But power to you if you make it work for you. Perhaps you have some resources I could use?
The counter should generally be part of the API as well for simple property tests. However property tests are not just about reverse testing but about invariant testing, like have it generate inputs into a state system, test that the state of it is valid each time and make sure it ends at a proper place given the inputs, even without knowing the values you catch a significant amount of bugs.
As a good example of state testing see the Elevator example for the C side of the QuickCheck library (which uses Erlang to do the testing) for how to think about it. 
Aspect: Testing as One Driver of Design
My exposure to property testing is minimal (e.g. worked through an elaborate a QuickCheck demonstration in Haskell) and for the time being Elixir Forum Property-Based Testing with PropEr, Erlang, and Elixir is a bit of a specialist topic for me to fully commit - but the reason it is staying on my radar is that I suspect that beyond the primary benefits it may impose beneficial design pressures on the code.
you find a rule that dictates the behavior that should always be the same no matter what sample input you give to your program, and encode that into some executable code—a property.
In order to use property based testing the STU has to be designed against somewhat coherent (and explicitly stated) rules that the tests can be based on (now if the same was only true for “business” logic). So if you want to leverage property based testing it seems the need for “rules” improves coherence. The flip side is that if you can’t be bothered to discover/refine those “rules”, you are not going to see the value in property based testing. With example based testing there is never any real incentive to unify fragmented, incoherent logic.
While this rant states that “You Don’t Need Referential Transparency” I’d be inclined to believe that property based testing would drive you towards preferring referential transparency.
However I still see property based testing as a rather specialized tool in the “testing” part of software development, likely useful for micro tests, possibly useful with collaboration tests, likely not appropriate for contract tests.
Some approaches to testing can be inefficient/ineffective (similar to the situation in process and documentation). Hypothetically property based testing should be more efficient than example based testing because it can cover more values with less effort. But the issue is that it can’t replace example based testing.
Given that developers will be exposed to example based testing first (and testing is a means to an end, rather than an end in itself - unless you are specializing in testing) they may never get exposed to property based testing.
Then there is the possibility that property based testing is only applicable and effective for code bases that already meet certain quality standards.
Which begs the question: could some software benefit from being “perfected” (i.e. designed) to be more amenable to property based testing and would that improve the software’s design from functional and maintenance perspective?
Chiming in, as I am also a big fan of TDD but not fanatical in my implementation of it.
I have experienced the same thing @Fl4m3Ph03n1x , testing in Elixir is requires a lot of arcane knowledge that will not arise from getting into the code and writing the tests. Elixir lacks a popular opinionated testing framework and it is easy to do wrong, or to architect your code base to make testing a slog.
I’m working on a blog post about this exact subject, so I will share some of my notes.
Keep in mind: Macros make the dream work! They let you write amazing abstractions for your code and I highly recommend getting VERY familiar.
There is a book by THE Chris McCord Search
First and foremost, there is a pattern we have yet to name but is mentioned over and over in the community to enable clean mocking and testing. You can find resources on it here:
a good reference impl of this is bamboo.
Additionally, I do property based checking and macro away as much boilerplate as I can.