|
It really depends on the degree to which you do it. I'd argue that just having one or two very basic acceptance tests is probably all you want when you're testing the waters with an MVP. The most all-encompassing test you can make; and make it from a client-side perspective (so: JS or Python or something exercising your HTTP API). For instance, if you were making a library app: test that a logged in user can add a book to it. That's as simple as: class AcceptanceTest(TestCase):
def testThatAUserCanAddABook(self):
r = requests.post("/books/", data={"title": "My New Book"}, auth=HTTPBasicAuth('user', 'pass'))
self.assertEquals(r.ok, True)
Then, do the absolute bare, hacky minimum to get that test passing: implement a server which simply returns 200 to that URL.As you're working, I've found that having that singular, overarching acceptance test will speed you up massively; there's no need to arduously step through your UI, or run through various httpie commands; the test covers you as you refactor to implement your user authentication, basic API, and backing database. So, yes: TDD can be a big time investment, and can slow down your launch if you fully break your work down into unit tests. But having simple, straightforward, all-encompassing acceptance tests can give you a great base for getting work done. (Note that after launch, once you start writing more tests, you should eventually throw away that acceptance test, as more componentised and faster unit tests replace it :)). |