Book Image

Implementing Domain-Specific Languages with Xtext and Xtend - Second Edition

By : Lorenzo Bettini
4 (1)
Book Image

Implementing Domain-Specific Languages with Xtext and Xtend - Second Edition

4 (1)
By: Lorenzo Bettini

Overview of this book

Xtext is an open source Eclipse framework for implementing domain-specific languages together with IDE functionalities. It lets you implement languages really quickly; most of all, it covers all aspects of a complete language infrastructure, including the parser, code generator, interpreter, and more. This book will enable you to implement Domain Specific Languages (DSL) efficiently, together with their IDE tooling, with Xtext and Xtend. Opening with brief coverage of Xtext features involved in DSL implementation, including integration in an IDE, the book will then introduce you to Xtend as this language will be used in all the examples throughout the book. You will then explore the typical programming development workflow with Xtext when we modify the grammar of the DSL. Further, the Xtend programming language (a fully-featured Java-like language tightly integrated with Java) will be introduced. We then explain the main concepts of Xtext, such as validation, code generation, and customizations of runtime and UI aspects. You will have learned how to test a DSL implemented in Xtext with JUnit and will progress to advanced concepts such as type checking and scoping. You will then integrate the typical Continuous Integration systems built in to Xtext DSLs and familiarize yourself with Xbase. By the end of the book, you will manually maintain the EMF model for an Xtext DSL and will see how an Xtext DSL can also be used in IntelliJ.
Table of Contents (25 chapters)
Implementing Domain-Specific Languages with Xtext and Xtend - Second Edition
Credits
Foreword
About the Author
Acknowledgments
About the Reviewer
www.PacktPub.com
Preface
Preface to the second edition
14
Conclusions
Bibliography
Index

Testing and modularity


One of the nice advantages of TDD is that it forces you to write modular code; it is not easy to test code that is not modular. Thus, either you give up on testing (an option, which I hope you will never consider) or you decouple modules to easily test them. If you did not adopt this methodology from the beginning, remember that it is always possible to refactor the code to make it more modular and more testable. Thus, TDD and modular/decoupled design go hand in hand and drive quality; well designed modular code is easier to test and well-tested code has a known quality.

When evaluating whether to accept this programming methodology, you should also take into consideration that testing UI aspects is usually harder. Thus, you should try to isolate the code that does not depend on a running Eclipse. Fortunately, in a DSL implementation this is easy.

Let's consider the quickfix provider we implemented in Chapter 4, Validation, which adds the missing referred entity; we...