bnorton
We're a great, growing team looking to hire a Frontend and Fullstack Engineer to complement our existing expertise. If you're in the Americas, take a look at the role description and see if you'd be a good fit
Fullstack: https://trychameleon.notion.site/Fullstack-Engineer-be6a2017...
Remember those modals, tooltips and checklists you have built but never really wanted to?! with Chameleon, the Product team can WYSIWYG those into your application with just a few clicks.
We're a great, growing team looking to hire a Frontend and Fullstack Engineer to complement our existing expertise. If you're in the Americas, take a look at the role description and see if you'd be a good fit
Fullstack: https://trychameleon.notion.site/Fullstack-Engineer-be6a2017... Frontend: https://trychameleon.notion.site/Frontend-Engineer-2665cd449...
Remember those modals, tooltips and checklists you have built but never really wanted to?! with Chameleon, the Product team can WYSIWYG those into your application with just a few clicks.
We're a great, growing team looking to hire 2 Frontend Engineers to complement our existing expertise. Take a look at the role description and see if you'd be a good fit!
https://www.notion.so/trychameleon/e38d308f67f641e8aaa0e4f68...
Remember those modals, tooltips and checklists you have built but never really wanted to?! with Chameleon, the Product team can WYSIWYG those into your application with just a few clicks.
We're a great, growing team looking to hire 2 Full Stack Engineers to complement our existing expertise. Take a look at the role description and see if you'd be a good fit!
https://www.notion.so/trychameleon/Work-with-us-at-Chameleon...
We have some interesting requirements that we must conform to in order to be part of our customer's web applications. We'd love to explore those constraints and benefits with you.. Brian - co-founder @ Chameleon
We've built a product that runs wholly inside another companies interface allowing them to create and edit right where it matters (engineering wise there are many challenges this presents).
Our engineering motto: If product can think it up, we can built it -- all product needs to do is figure out what is most important ;)
User.where(:email => email).first.tap_if(:present?) {|user| user.send_update }
#tap_if - a new type of conditional for Ruby
It is common practice (and a good one) to mock the server from the JS perspective as to isolate it, but I dont think this in itself gives it integration test status.
I feel that hackfests/days are not really all that enjoyable but am just as likely to be prime co-founder material...
For example this line states that if you are given 20 records that 20 make it into the view.
expect(view.$('.persons li').length).toEqual(20);
This mocks out the server to give 20 results back and simply tests that the template iterates over the returned collection (given that the 'reset' binding for view.render is in place). You are specifically not in an 'integration'.
As for the argument for not using capybara for speed reasons - it seems that the speed difference is acceptable given the confidence and power it gives you.
This is not the same as an integration (acceptance) test. Whence you mock the server you can no longer be confident that a breaking change was not introduced across the stack.
The purpose of integration tests is that you are the user, and express your functionality in the same manner that the user would.
This is not that. It is therefore not an integration test.