Does it make sense to test business functionality before doing a code review?



  • Currently, we have a feature branch development environment. Features are specified as stories that each developer takes on. Once a feature is done on a feature branch, a pull request for said feature is opened. Now two steps are left: a) test business functionality: Somebody checks whether the feature was actually implemented as specified by the story. This should ideally be somebody else than the developer b) code review: Somebody does a code review on said branch. This should ideally be somebody else than the developer

    a) has an impact on b): If the functionality is not implemented as desired, the code must definitely change.

    b) has an impact on a): If there is a bug in the code, the feature might be impacted.

    Based on this, it seems to be a good idea to first test the business functionality (a) and then do a code review (b).

    Is this true? What are flaws in this setup?

    Further question: If this is a way to go for it, what kind on tooling do you use to deploy many branches? Having microservices etc. will quickly give rise to conflicts (e.g., ports overlapping, server resource limitations, ...)



  • It seems rather nitpicky to determine if the order of reading code and performing any manual testing, especially since it's an iterative process.

    Since it's not stated, there's an assumption that the developer who did the work didn't just write code and throw it over the wall. They tested it, by some combination of writing automated test code as well as running some manual tests over their changes. When the code review is initiated, the developer has reasonable confidence that what they are submitting is correct as far as they have understood the work before them and the review not only includes the product changes but all automated test code as well. If any manual testing was performed, the developer should be able to explain what testing was done.

    If this holds, then I don't see why you need to draw a distinction between "test business functionality" and "code review". Perhaps don't think of it as a "code review", but rather a peer review of the work - the production code, the automated testing, and the manual testing performed. The reviewer is really checking the quality of all of these things, and perhaps doing some additional exploratory work to confirm that it is suitable. Depending on the nature of the changes, the effort can be put toward different things at the discretion of the reviewer.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2