Documenting business logics of legacy application having no unit test

Question

I have joined a team in company and this team owns few services, which are used widely by many other user facing internal/external UI apps and other internal apis.

My manager gave me rough idea that these services are responsible for, let's assume, around $1B worth of traffic, or something like, so idea was, it's super critical.

There are tons of business logic, lots of if/else in c# code. Also sql Stored procedures and sql function are used. I have worked in these kind of code in past also, so I know these services are complicated too.

System mainly in maintenance mode, so no frequent code changes.

There are no unit tests and very minimum documentation.

There is an effort going on to rewrite these services side by side, without modifying this existing, and some migration plan. My manager want me to understand business.

Need for frequent releases, data issues in this monolithic in various environment, old infrastructure and high maintenance causing money, are few reasons. There is an initiative for cloud Native microservices in my organization.

In past, for these kind of scenario, I wrote integration test first. But this time I am trying to write this in BDD style, not sure if this going to be a right approach. I never worked with BDD, but read about it. Seems output of BDD is good documentation, with other benefits. Nevertheless my ultimate aim to document business logics so that we can use it while rewriting this application. Refactoring seems not an option here.

Suggest me if I am going in right direction, any other points I should take care of, on effective documentation of business logics.

Answer 1

First, read Working Effectively with Legacy Code. Then read it some more.

Other than that, my own take on your specific situation:

• A big bang rewrite is going to be pretty much impossible to pull off. You've got a complicated system which is talking to a lot of other systems, making the whole thing a giant system. And you want to replace the central part, undocumented and untested as it is, with new code. And it sounds like any amount of downtime is going to cost $$$$. So writing tests and then refactoring (again, book above) carefully is the way to go.
• BDD tests are great in theory.
  1. Non-programmers can write tests! Except not really, any more than non-programmers can write SQL. Both look vaguely like English, but there are strict rules and you very quickly run into problems trying to translate the umpteen different ways of phrasing something into code, or conversely, trying to teach non-programmers to (effectively) code.
  2. It's fast enough! Sure, until you actually have a reasonable amount of tests, at which point a single run will take days. This is one thing that is glossed over in pretty much anything I've read about BDD, acceptance tests and end-to-end tests (as these terms overlap considerably): your first test will probably run in milliseconds, but in realistic applications a unit test covering the same code will run orders of magnitude faster.
  3. It's readable! No, the test cases themselves may be kind of readable but clunky English, but as a programmer you need to understand all the code which goes into running a test. BDD tests inevitably end up glossing over details which are handled in lower layers, which just as inevitably comes back to bite you when those details turn out to be important to your tests. In plain acceptance tests you're much more likely to see where things have been glossed over (things like having to pass DisableCertificateVerification flags or creating the objects you are manipulating). With BDD you're also dealing with one extra language, and that is not a complexity you should take on lightly.
  4. My IDE supports Gherkin! Well, kinda. Until you mix givens and whens (because sometimes something is a prerequisite and other times it's the thing under test), loop over test cases and more complex features, and your IDE gets very confused trying to go to the right definition.