Ruby Conf 12 - Boundaries by Gary Bernhardt

Forgive me for being vague and brief, but I've been trying to test my UIs for the last year or so and this is what I've come up with. I've found the ideas in Gary Bernhardt's talk, Boundaries (1), to be very helpful in figuring out how to test interactive web UIs. The basic idea is that DOM manipulation can be an "imperative shell" with as little logic and as few conditionals as possible. Derive the state of your UI component with separate functions and methods that return plain values (a "functional core"), and write tests for those because testing for values is easy. So no, don't test for the presence of classes and IDs. Test your imperative shell once, maybe even manually or with an integration test, and that's probably enough. Angular and React both encourage something like this approach, but you don't need those technologies to do it this way. In Backbone, for instance, just try to avoid conditionals and logic in your templates and render methods. If you think your UI piece needs to render with conditionals because it can be in different states, ask yourself if those states are just appearances that can be programmed declaratively with classes and CSS. Also, testing is so much easier when you limit API surface areas. So if you're using a library like Backbone, where models and views both have many methods with many ways they can be called and used, don't give them direct references to each other. I've had some success in having models and views communicate only with a gl

Many of the advantages of microservices can be achieved by refactoring your monolith code to be less monolithic. I would suggest using functional styles wherever possible, plenty of isolated unit testable code, and a hexagonal architecture [LINK] that pushes all the I/O, mutation, side effects, etc. to the very boundary of your code. Also see Gary Bernhardt's "Boundaries" talk for more interesting thought in that vein [VIDEO]

I recommend watching this talk: [VIDEO] Both, unit and integration tests, are imperative. Integration tests point in the general direction of where an issue might be but unit tests are more precise.

Here is the infamous Nagappan TDD paper from Microsoft Research [LINK] Also discussed in this infoq article [LINK] Here's someone's thesis paper on it, with data: [LINK] There's also interesting discussions like this [LINK] "it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly." This has also been my own experience. This person's comment also is interesting and has data [LINK] Some of the above is empirical (read: scientific, no-bullshit) data. My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving" I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk [VIDEO]

if you are a rubyist, I can't more strongly recommend watching this video, which has nothing to do directly with Elixir (in fact it precedes elixir by a couple of years) but if the topics that Bernhart (of wat fame) brings up resonate with you, then you will really like Elixir. [VIDEO]

> I find some problems are solved better in an OO way such as interacting with a relational database. I've switched to functional interactions with a database, (Elixir/Ecto) and really, it's much better. In particular the explicit and declarative nature of the database interactions combines the convenience of an ORM with "not hiding important gotchas from you". I'm not arguing for pure functional systems (which I can see going very poorly with relational databases). There are some things that objects are good at like caching state as a model. But even here the FP systems typically do it better via FP actors and (again, impure) message passing, which enforces no-shared memory, and at least in erlang virtual machine systems, couples segregated state with limiting blast radius for your systems failure domains, which is 150% the "right thing to do". Of course if we're getting pedantic, this is even close to OO the way that Alan Kay imagined it, than what the OP and GP talk about, and I don't consider that to be OO in the contemporary, colloquial sense of "everything that happened after Bjarne Soustroup invented C++" I highly recommend this video for a more philosophical take on how to do "impure FP" without OO that is informed by a decade of industry experience: [VIDEO] which is by Gary Bernhardt (of WAT fame) > I look for the right tool for the job rather than some idealistic purity This is all about right tool for the job. IMO, FP code is easier to read, easier to reason about,

This isn't an article but reading your post reminds me of the presentation by Gary Bernhardt titled "Boundaries", [VIDEO] I would be interested in looking at the article(s) if you can find them again.

I have been researching into several testing approaches and so far in my experience yes fakes are better than mocks. But what is even better is not having to fake or mock stuff especially for testing business logic. One of the problems we get ourselves into is abstracting service io code into functions and calling them from our business logic code. This forces us to mock all the io calls, instead we should be doing the opposite i.e abstracting business logic into discrete functions of pure data in and out and then calling those functions from our io code. This way we can test the business logic independently of the io code. Testing the business logic now becomes quite simple and one can leverage property testing to further boost our confidence in such tests. Many times the ramaining io code is just calling other functions and doesn't need to be tested. Several other ideas that relate to this are hexagonal architecture, Domain Driver Design, clean architecture and functional core with an imperative shell. Some resources to further explore these ideas: Clean Architecture in Python - [LINK] Why integrated tests are a scam - [LINK] Boundaries - [VIDEO]

A few years ago I was on a team and the dev lead had a practice of sharing Gary Bernhardt's Boundaries talk every time there was some degree of rotation or churn on the team. Almost part of the onboarding. As a functional programming aficionado, I didn't need the sales pitch, but it was the presentation that was gripping. Keep in mind, Ruby isn't a functional language, but here was this presenter describing essentially how you write good Haskell code, but in Ruby! A language that makes it so easy to mutate in place that it's known for libraries that "monkey patch" base classes and can change the definition of operators and functions at runtime! Fantastic talk, fantastic presentation. I now share it with my new engineering colleagues too. Here's the talk where he talks about imperative shell, functional core, "Boundaries": [VIDEO]

> Jose has really thread a needle with Elixir I feel. There was kind of something in the zeitgeist ready for this... This was a video by Gary Bernhardt in 2012 (that's like, Elixir -2 years?). I've queued it up to where he talks about basically wanting to go live on a cruise ship, fork rubinius, and rebuild ruby on top of erlang. The main chunk of the talk is about the software pattern that Phoenix and Elixir really tries to get you to adopt. [VIDEO]

This talk [1] made me conclude something along these lines. You need side-effects to make anything useful, just make sure they're segregated in a specific place in your program. This makes it easier to make most of the program pure and make it clear where the dangerous stuff happens. [1] Boundaries by Gary B. from Destroy All Software [VIDEO]

You've got the gist of it. By decoupling your function from the state of your application, you can test that function in isolation. For instance, you might be tempted to write a function that opens an HTTP connection, performs an API call, parses the result, and returns it. But you'll have a really hard time testing that function. If you decompose it into several tiny functions (one that opens a connection, one that accepts an open connection and performs the call, and one that parses the result), you'll have a much easier time testing it. (This clicked for me when I wrote code as I've described, wrote tests for it, and later found several bugs. I realized my tests did nothing and failed to catch my bugs, because the code I'd written was impossible to test. In general, side effects and global state are the enemies of testability.) You end up with functions that take a lot of arguments (10+), which can feel wrong at first, but it's worth it, and IDEs help enormously. This pattern is called dependency injection. [LINK] See also, the "functional core, imperative shell" pattern. [VIDEO]