Longevity Framework Cares About Code Quality

We care a lot about code quality here at longevity framework. You can rest assured that longevity is well-designed, has clean code, and a robust test suite. As of now, code coverage comes in at 95.02% statement, and 93.44% branch, as measured by sbt-scoverage. What software projects do you know of that have that kind of coverage?

Longevity relies heavily on emblem, a utility library developed in tandem with longevity. Emblem code coverage is 92.03% statement, 87.96% branch. Both emblem and longevity have more test lines of code than main lines of code.

Longevity has an integration test suite, comprised of tests that run against a test database, and a unit test suite. We strive for full coverage of the longevity code base against each test suite individually. The integration test suite coverage is 91.88% statement, 80.33% branch.

It's not possible to write unit tests against most of packages longevity.persistence and longevity.exceptions.persistence, since this code involves database interactions. But in longevity code outside of these two packages, unit test coverage is very high. Package longevity.subdomain has 100% unit test coverage, both statement and branch. Package longevity.context has 91.67% unit test coverage.

Of course, the longevity test suite is not just about coverage percentages. There is a suite of integration tests covering nearly every possible subdomain feature we support, as well as an integration test suite for every kind of query you can write.

Test coverage is just one part of code quality. We are constantly refactoring and cleaning up code as we add new features and enhance the framework. Our coding style is consistent throughout the codebase. Source code files, classes, and methods are short. Method and variable names are carefully chosen.

If you've looked at our User Manual, Getting Started Guide, or Scaladocs, you already know that we care a lot about quality user-facing documentation as well. Every public element of the longevity API has non-empty and informative Scaladoc comments. Also, nearly every code example in the user manual is included in the longevity test suite, so you can be assured of their correctness.

I have a personal pet peave about the coding examples that occur in most library documentation: the import statements are not included, so that you are left guessing where the classes and types used in the example come from. This is even worse in Scala than it was in Java, since it is not always possible to do a name search in the left sidebar of the Scaladocs to find what you are looking for. Consequently, every example in the User Manual and Getting Started Guide includes a complete set of import statements, with no wildcards.

Longevity is built to last, and it is built with you the user in mind.