1. 11

    Unit tests are intended to speed up development. If they do the opposite, then yes, you should stop writing them, because they’re not useful to you.

    Two ways in which unit tests do speed up development:

    • When tests fail, unit tests help pinpoint the part of the code that needs to be fixed.
    • Integration tests often take longer to execute than unit tests, so a good set of unit tests can speed up the change-compile-test cycle.

    The author hit the nail on the head here:

    When a large change lands, unit tests, in the best case, need to be heavily modified, and in the worst case are obsolete and need to be removed.

    In a development cycle involving unit tests, we do our best to avoid large changes. If a given change requires changing lots of tests, then either the change itself is too large, or the tests are not really unit tests.

    1. 2

      Well put. This was also going through my head while reading the article. “Unit” and “integration” tests serve different purposes.

    1. 5

      I’ve been working on lasso, which started as an excuse to play with Phoenix LiveView. Starting to feel pretty good about it, might even upgrade to a non-free tier at gigalixir.

      1. 2

        lasso looks really cool, I’ve built something similar for my company but it isn’t nearly as cool as yours. I looked into liveview for something else and it looks like a good alternative to just pass JS around for some things.

      1. 1

        The question, then: “is 90/95/99% correct significantly cheaper than 100% correct?” The answer is very yes.


        Great article. And I’m even more hyped to read my fresh copy of Practical TLA+.

        1. 16

          I feel like there’s such a big difference between the JS world and pretty much any other language ecosystem that it’s hard to identify with articles like these unless you’re a JS front-end dev. At least my own experience is that most other communities has moved on from FOTM frameworks since long, or never even got into that mode. I guess it’s got a lot to do with how fast browsers evolve compared to “backend stuff”.

          1. 9

            As a backend developer I’d say it also has got to do with the fact that the fundamental problem the front-end is trying to solve is so hard that we haven’t come anywhere near an acceptable solution. The number of deeply interacting concerns are simply too high. So people always come up with completely new ways of doing things that do improve on the state of the art.

            1. 3

              I think the fundamental problem the front-end is trying to solve is undefined.

              1. 1

                User experience is undefined? O_o

                1. 2

                  UX functions like language. An intuitive UI is defined largely by what the user already knows, and it suffers from “slurring” as seemingly redundant indicators shrink away to nothing, “punning” and “coining” new terms, and, of course, fashionable ways of expressing things and fashionable ideas to express.

                  So even if it is kind of “defined” in what it means, it definitely isn’t as “stable” as core algos are.

                  1. 2

                    I don’t think there is a single problem. We all know many examples of products and services where user experience is less important than ad profits. I would say the most fundamental problem for front-end is minimizing time and effort required to push new products and services out - while maintaining acceptable user experience.

            1. 6

              I’m pretty excited about LiveView as a way to sprinkle some interactivity on phoenix apps without having to venture out to JS land. Can see it being a pretty good way to enhance admin UIs and the likes.

              1. 11

                I can’t keep this to one thing, sorry.

                Go slow & correct first. Pre-requisite to be able to eventually go faster and correct.

                Learn new languages. Helps with thinking about problems in different ways.

                Short feedback cycle! Anything that improves this will make you faster – TDD or at least test first development, and Continuous Deployment are big ones.

                Spike and Stabilise pattern (this and more related good stuff by Dan North in https://leanpub.com/softwarefaster)

                Pair programming can sometimes make you faster and better, depends on the problem and the pair.

                Drawing things (whiteboard or pen and paper) can help a lot

                1. 10

                  Good idea, writing a nice README is important and can be hard. I don’t agree with the badge overload some of these seem to encourage though. I feel like a lot of the time they do not add any value, for examples badges like: “contributions welcome”, “built with <3”, or “code style: standard” – come on. Write it in text or skip it IMHO!

                  1. 7
                    • Skateboarding. Picked it up 3 years ago again, after a 15+ year break. So much fun (and frustration), and good workout. Slams are worse though :/
                    • Programming. Always got some side projects going.
                    • Listening to music. Been an obsession for decades. Most genres. Really into contemporary stuff.
                    • Art – Painting, sketching, and some digital stuff (using processing or quil)
                    1. 3

                      In my team we only use some of the simpler AWS services (so far), like S3 and SQS. For those a good option for us was to isolate the AWS interactions, and then substitute them with test implementations (in memory queue for sqs, local file system for s3) when needed. To test the production modules themselves we use pre-baked API responses (gotten from real interactions with the AWS APIs).

                      Another option I can see is to use test prefixes (or a separate VPC) on your AWS resources (queues, s3 bucket, objects) for integration tests. Would maybe cost more, but is probably safer.

                      1. 7

                        Is this this? I was very excited about that UI framework but never saw any code released publicly.

                        Edit: I answered my own question. This is it! Looks like the ElixirConf 2018 video is here.

                        1. 3

                          Yep. This is very exciting stuff for the Elixir/Erlang ecosystem! Great talk as well.