JavaScript, In Memory Gateways, and Real Gateways

[Dave Schinkel]

Right now, I've have had a love hate relationship with JavaScript once I hit the wall of really wanting interfaces.  The fact that I can't share an interface really blows.  When I was coding in C#, we had used interfaces for our gateways and so my in-memory gateway and real gateways were able to share the C# interface.

Now that I'm doing all node.js, there's no real good way to do this.  Since JS is not typed, you have crap like duck typing (what a mess), and really what else?

So for my use cases tests, I'm passing business entity instances from each test into my in-memory gateways.  I then inject that gateway into the use case via node module object property.

It'd just be nice if I had an interface to ensure that my real and in-memory are sharing the same interface and adhere to it.  Because right now what I'm having to do is copy the method sigs from my in-memory modules to my real gateway just to manually maintain the "contract" that does not really exist in JS.

I am looking for a better way to do this.  Thoughts?  My collegue is trying to get me to want to code GoLang.  It's got interfaces!!  I'm so tempted.  But yea, not gonna change our code now, it's gonna be node.js.

[Sebastian Gozin]

Can't you reuse the test suites for both gateways to some degree?
At least for the tests which exercise the methods.

[Caio Fernando Bertoldi Paes de Andrade]

Write a suite of contract tests.

Caio

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Dave Schinkel]

yea you create gateways (in-memory and real) based on a shared interface but you still have Data Layer code that could bomb out...I guess those are left to integration testing.  I can't think of any other way, and testing that is integration testing anyway...it's hitting a real DB.

[Sebastian Gozin]

Yes those contract tests often need to execute at an integration level.

[Eric Smith]

You've got a couple options. JavaScript is even worse than most dynamic languages in this regard, so it gets fairly gnarly. 

1) You could use sinon.js for mocking in this case. I believe it has built in facilities to check if the object you are mocking actually implements that interface. This is a common problem in dynamic languages.

2) You could pass the actual gateway to your in-memory gateway. Each in-memory call could validate that there is a corresponding method on the actual gateway. You'll need to check parameters too. You won't get perfect guarantees because you can't really check the types, and if you have variable arity on some functions those can't really be validated, but you can make some reasonable assumptions. Pretty code-intensive. 

3) You could also write contract tests, and make sure your in memory tests and your database tests both pass. Essentially validating they have the same interface. These would have to be updated each time you make a change to both. 

I'd probably end up using sinon - but primarily because I have it around anyway for mocking http requests.

[Dave Schinkel]

Thanks Eric, very helpful.  I had been pushing off Sinon.js but....might just try Sinon.js, I because so far, I have been writing custom mocks.

I'm also looking at  Flow  static type checker by Facebook, to make it behavior more like a typed language and seems pretty clean.

I don't like typescript, because it requires you to create all those funky files.

I didn't know about injecting the real into the mock gateway, interesting I'll have to look at that too.