

Building a testable Go web app - rgarcia
https://sourcegraph.com/blog/building-a-testable-webapp

======
tkinom
I personally actually prefer your testv0 method. The way I understood it is a
full stack testing that requires putting data into the DB and query them back.

What's wrong with that? It might be just a bit slower but for me that kind
test is a lot of comprehensive. I have in the past has to slightly change the
DB schema. Because of full stack test coverage were in place, full functional
tests make all the bugs caused by schema change visible immediately.

For me, schema changes in DB cause some other operations to the DB failure is
much difficult to detected and fixed if the issue is not visible to the
developer immediately.

It might be slower (~a few minutes for ~300 full funtional test scripts run
directly from the web-browser side) instead of seconds in your case, but I
think the time is well spend for how quickly complex issues can be discovered
and fixed.

BTW, I keep track of all DB operations (sql query) time as part of the json
response. If they are > 1 milliseconds (SSD HD), I will flags them as
potential issue in bugs DB for future investigation for SQL optimization.

It should be easy to add the SQL query response time to a performance DB to
track and change over time/sw version.

~~~
jfroma
I agree with you, and for me the classification "integration" vs "unit"
doesn't add anything. I'd rather distinguish between slow and fast tests.

In my opinion TDD is top-down (instead of bottom up) you must start with these
things because you are not sure the abstractions you will have at the end.
Your design and abstractions need to evolve from tests.

~~~
spacemanmatt
In my experience TDD is orthogonal to project design strategy. Whether your
testable goals serve a bottom-up progression or a top-down progression, TDD is
still a useful mechanism for advancing the feature set.

------
spacemanmatt
I didn't see any schema tests for the db. Testing the DAO is its own concern,
and I can't consider that as unit test coverage for the schema portion of the
project. I would normally be looking to something like PgTAP here.

(For the "oh really?" crowd, here's a brief rundown on what I often test:
object permissions/owners, function correctness, non-trivial constraints,
triggers (usually existence testing, sometimes functional verification),
application-global data. And yes, it is great to have all that nailed down
before diving into writing a DAO)

------
crolek
They switched from angular to essentially a static site for SEO reasons. I
wonder if they're batch generating the static pages or making them dynamically
on request.

~~~
freyr
That hits close to home. I recently built a single page app with Backbone and
SEO traffic is non-existent.

So now I'm dynamically generating pages on the backend, and serving them along
with the javascript app so there's some some indexable static content. There
are a few ways to directly reuse your client-side code on the server, but they
all seem pretty hacky and convoluted.

I bought into the notion that the backend should just be a client-agnostic
API, but that's an extreme position that should be considered when your
site/app doesn't have any indexable content to begin with. If I could only go
back in time...

~~~
arianvanp
ReactJS is awesome here. You write clientside code but you just run that
clientside code on the server on request to prerender an initial DOM. And then
your client hooks into that DOM. It has worked like a charm for me.

~~~
freyr
I tried an early version, and I was impressed, but my app relied on an CSS
transition that was causing an issue with React. It looks like they've
improved on that with ReactTransitionGroup, so I'll check it out again.
Thanks!

