Starting with Test Driven Development in JavaScript
Are you scared of making changes to our code? Do you spent a lot of time debugging or maintaining your code? Are you new to JavaScript and do not know the language’s many pitfalls ? Do you fear cross browser issues? Then you should start with Test Driven Development (TDD). Manual Testing of SAPUI5 applications is time consuming and error-prone. Since your application should run on a lot of different browsers, testing them all manually in detail is impossible. Kent Beck states that the goal of test-driven development is clean code that works. TDD not only provides fast feedback, but also improves the structure of the code.
There is already a lot of great content out there dealing with Unit Testing in JavaScript Environments. In general, you can and should apply these concepts also for developing SAPUI5 applications. Since it is always hard to start and find the most relevant information, this blog post aggregates some links to useful content:
- Start with the QUnit page and implement some smaller examples. QUnit is delivered together with SAPUI5:
- Afterwards, if you have never written Unit Tests in JavaScript before or do not know the concept of test doubles, you should have a look at Christian Johanson’s blog series:
- “The secret of testing is writing testable code” (Misco Hevery). If you are not sure how to structure your code to get it testable, read Uncle Bob’s book about clean code or watch the following video:
This blog post is part of a series, like the following blog post to stay tuned and get updates about more topics around software engineering with SAPUI5 and JavaScript:
http://scn.sap.com/community/developer-center/front-end/blog/2013/12/12/engineering-in-javascript
Hi Klaus,
as for me, looks a little bit academic, and not 100% applicable to SAPUI5.
* Who will write the tests for the tests?
* Is it reasonable to test code, based on non TDD-conform, non open-source developments?
I mean SAPUI5 works only as a frontend for NWGateway or HANA Data Services. The main code and the most important one is there.
Regards
Konstantin
Hi Konstantin,
the origins of TDD are not academic, it has been used by a group of software professionals first, see:
Ten Years Of Test Driven Development
I know many developers doing TDD for SAPUI5 applications successfully. If you have a more sophisticated SAPUI5 app, you have a lot of JavaScript code (formatting, validations, calculations, orchestration..), which should be tested and the dynamic nature of the language also has some pitfalls.
For me TDD was really helpful.
TDD - as I use the term here - is more about writing testable code. In UI applications it is usually harder to do real TDD. Whether the developer writes the tests before implementation or afterwards is secondary. However, writing tests first typically produces much better tests and costs less time.
Maybe it is harder to write TDD-conform code for UI applications, compared to backend development, but if you apply good practices and discipline it can be achieved. In the coming weeks I am going to publish several blog posts around the topic of TDD-conform code.
Have you tried TDD? What were the issues?
Regards
Klaus
Hi Folks,
What scares me is how many Javascript projects start without the necessary supporting backbone: professional development tools, training, experience.
But TDD, QUnit and friends help to survive.
Our project currently writes a framework plus an HTML-5 application (SAPUI5+CVOM) in Javascript, 5800 LOC. Project Working Capital Analytics (WCA) together with the Analysis Path Framework (APF).
After 1 year of development we are now in the 2nd week of correction, shortly before our final delivery.
We would be dead now if we hadn't continuously invested in QUnit test coverage. I would go as far as saying that in those parts of code where the coverage is lower we see the majority of messages.
One of our major challenges will be how we could bring major parts of our UI into electric testing. Which is necessary since we will be forced to migrate from UI5 commons to mobile soon. In the ideal, a finding (bug) would be turned into a unit test case before correction. Then, manual re-testing overhead could be reduced.
One area where we really created effort was wrong test patterns and wrong test isolation. Unfortunately, we created singular test doubles that later turned out to be bottlenecks during refactoring, creating dependency ties all over the code. It took us months to improve. The reasons for that failure was too small experience in TDD and Javascript.
A further issue we only solved rather late is regression tesing for local development. QUnit Composite Plugins | QUnit helped us to overcome the issue, after we had failed on KARMA test runner since our isolation of tests against other tests was insufficient (each QUnit runs in its own session!).
Hence, for projects starting on JS, it would be helpful if they could get Best Practices and Patterns to avoid the re-invention of the wheel.
Also, what seems to be badly missing too is a kind of GIVEN-WHEN-THEN oriented kind of complementary test description which might help to catch functional requirements and avoid getting bogged down by technical details like in many Unit tests.