Re: "bottom-up" TDD and common behaviors
|
My team recently had to switch from Hapi to Express (or from Hapi 14 to the new version of Hapi which has some major breaking changes) because Express has a better security update policy for us.
The change was pretty simple because we wrapped all our calls to the framework in an isolated layer.
I wouldn't say we made our own framework, we just made wrappers for the subset of the framework that we directly use.
On Fri, Dec 6, 2019, 02:21 Brian Marick < marick@...> wrote: That raises an interesting general question.
"The technology" is a web framework and its linked database framework.
The risk of those changing in a way that breaks a lot of old code is pretty small. How much effort should we spend insulating our code against low-probability events?
Isolating my code from Ecto would in effect mean inventing a *new* interface to a RDBMS. Does it really seem likely that I¡¯ll do that better than the Ecto designers?
P.S. I need to spend some time thinking about how FP ideas and OO ideas play together. My opinion has been that, leaving aside inheritance, typical FP languages are not different, in practice, than OO languages. But I wonder if that¡¯s right. On Dec 4, 2019, at 12:43 AM, Avi Kessner < akessner@...> wrote:
So this is definitely required behavior and it will be your own, so it needs to be tested. On the other hand, it's a very specific implementation detail which could change when the technology changes and we don't want that to impact actual behavior related tests about animals.
What I would do is make a transformation decorator and then test sample data to see that it gets transformed correctly.? If Ecto ever changes, that transformation decorator can do nothing if needed. You basically need a map of fields that can be changed and the transformation needed for that field.
A bit more work, but it allows for a change in Ecto or a change in understanding of Ecto to not impact the main test suite. On Wed, Dec 4, 2019, 01:50 Brian Marick < marick@...> wrote: Yes. On Dec 3, 2019, at 5:31 AM, Avi Kessner < akessner@...> wrote:
If I understand correctly, the code here is specifically?for doing an Ecto transformation, correct? If you decide not to use Ecto the need for this abstraction is removed?
|
