开云体育

wrote: I know. :) This matches my experience. We had this discussion back in Rochegude about the desire to write tests for the pieces, but then wanting to trust composition to glue those pieces

Hello folks, I just came across this Groups.io - thanks JB. ?Since the best TDD minds in the Universe are here maybe I can get some help learning... My area of study these last few months has been

Hi, My own experience isn't interesting as caml was one the first language I've learnt (25 years ago) and don't realise if changes I notice are due to the language itself or the paradigm. So I'm

Not what you asked, but when I was writing two (relatively simple) front ends in Elm, I deliberately didn’t write tests, relied on the compiler. I was disappointed in the results, as I found more

Hello J.B., This is a subject dear to my heart and I have had some experience doing various forms TDD in Haskell in the past years, after more than 10 years trying to practice in Java. I even

Hi, folks. I'm curious about your experiences in test-driving in type-checked FP languages. I've worked a little in Elm and I'm playing around with Purescript. I have noticed a few things, but I'm

Hi, folks. I've downloaded this group to the free plan on groups.io, so if you notice anything lost or broken as a result of this change, then please let me know. As far as I can tell, nothing

It depends, query handlers tend to have a repository interface injected, the repository encapsulates the EF LINQ in a read only way.? Command handlers will generally perform operations on EF

Is the design such that handlers manipulate EF collections directly?

Is it possible to place an object in a desired state without all of the builder steps? If so, you could then give it stimuli and test just single state transitions. I would be concerned, if I worked

Yes, I can see a fair number of tests that are currently using common setup steps.? These could be encapsulated at a higher level of abstraction and doing so will remove duplication in the test

Do you have common use cases where you can use the builder pattern to create the context? Or is the set of steps different in each scenario? brought to you by the letters A, V, and I and the number

For me, it's great that you have 2 independently deployable pieces. Though I would ensure I also had independently runnable tests. With the exception of having contract tests to test your expectations

The in solution 'framework' that has evolved for these tests does have a bit of a system test feel to it, although it is being leant on to test drive new classes with new behaviours. Here's an example

I’m a bit confused by your description, as it sounds as though you are doing system tests. That’s the most obvious case in which you’d need to “replay all the steps the application would

I am currently working on what you could categorise as a workflow automation product. The product is comprised of independently deployed front and back end components. The core domain is realised by

My only problem with the repo is that it presents a 'straw man' argument to the Detroit School (https://github.com/testdouble/contributing-tests/wiki/Symmetrical-Unit-Test). For example, a lot of

On Thu, 3 Sep 2020 at 13:32, <rold9888@...> wrote: > On Thu, Sep 3, 2020 at 12:31 AM, Walter Prins wrote: > > Note that the context here is not greenfield TDD but bringing existing > code that

I think this talk is a great place to understand how Justin approaches mocks and TDD: https://blog.testdouble.com/talks/2018-03-06-please-dont-mock-me/ His style though is an iteration on the

On Thu, Sep 3, 2020 at 12:31 AM, Walter Prins wrote: > > Note that the context here is not greenfield TDD but bringing existing > code that starts entirely without tests into testing and refactoring