Testing in a container

[Charlotte-Holt]

New topic based on the MicroShed work on how to test in a container. See the resources below. Adapt from the RHR document to add more useful information. It will be remote included in the RHR docs.

From LC: This topic needs to be more of an intro/concept to integration testing with OL - why, what do you achieve, what do you mean by 'integration testing' (as opposed to other types of testing), and what are the challenges that MicroShed resolves? What does MicroShed provide, and what alternatives are there (if any)? Explain how it works with the code snippets but less of a task/guide and more explanatory. Then link to the new(-ish) guide https://openliberty.io/guides/microshed-testing.html for help actually doing it.

Double-check with Alasdair about whether we should also link to Arquillian still.

Contact: Andy Guibert

Resources:

• https://github.com/PurpleLiberty/docs/blob/master/docs/modules/testing-with-container.adoc
• https://github.com/MicroShed/microshed-testing/blob/master/README.md
• https://openliberty.io/blog/2019/09/13/testing-database-connections-REST-APIs.html

[dmuelle]

Peer review

Define/introduce Testcontainer ?

change "With MicroShed testing you test your application in the same container that you use in production, thus reducing the risk of test failure."

to With MicroShed testing, you reduce the risk of test failure by testing your application in the same container that you use in production.

Why integration testing - possibly reorganize this section? change In integration testing, you can put together individual pre-tested modules and test them as a group. Integration testing follows unit testing. The modules used are previously unit tested, but now they are now tested as a whole to evaluate compliance and functionality.

to Integration testing follows unit testing. After individual modules are unit tested, integration testing looks at the modules together to evaluate their performance as a group.

"You can address this issue by testing your application in the same container that you’ll use in production."

watch for future tense- "You can address this issue by testing your application in the same container that you use in production."

don't use dev/test - from IBM Terminology app dev/test (noun) Usage Do not use "dev/test" unless it is part of the established terminology and is spelled out as "development and testing (dev/test)" on the first occurrence.

nonrestrictive clause needs a comma "test against a running Open Liberty server in non-development scenarios{,} such as CI/CD" pipelines."

"...testing, first add the microshed-testing-testcontainers and junit-jupiter artifact IDs"

This sentence is in a codeblock but doesn't need to be...

In cases where a Dockerfile or container image is not available, use the microshed-testing-liberty

[lauracowen]

Thanks for this draft. I like the general approach of this topic. I think it just needs more detail in the first sections. Also, the section "How it works" doesn't really explain how it works but how to use it.

With regards to what AndyG said about having the guide and the microshed.org website already, that doesn't negate the need for us to have a topic like the one you're writing in the main OL docs. There needs to be something that introduces the concept of integration testing: what it is and why it's important, then introduce the problems that can arise that are then solved by using microshed. Then describe what microshed is and how it does what it does (eg containers etc).

We need this in order to give context to what MicroShed is for (otherwise we'd just be pushing people to a guide or site with no context about why they should care). Also, we need to have this intro in the RHR docs to again give context before pointing them off to the guide and site for worked examples and more detail.

Can you talk to Andy to get a bit more about what integration testing is and why it's important. Can you also check the definition that you have already. Also, ask him if there should also be a discussion of Arquillian and how it fits into this, if he feels it does (when you'd use Arquillian and when you'd use MicroShed - the problem each addresses and how).

Some points to include (if Andy agrees they're correct!):

• unit tests (test small inidividual bits of code, eg individual methods?? check) are easy to write and fast to run but integration tests are harder to write and slower to run, but by running integration tests (tests how an app works and requests info from other services??? check), developers have more confidence that the code is working the way they want it to work.
• Microshed is aimed at application developers to make it a lot easier to write tests by xxxx (I think using annotations etc but check with Andy) and subsequent releases are making the tests faster to run.

I think you should remove from this topic the info from "To write a test…" onwards - the topic shouldn't be trying to tell the reader how to use MicroShed. Keep the topic as a conceptual introduction. However, I think that can include a code snippet that illustrates how it works. So you could (unless Andy has a better idea) include the first two code examples (and explanations) from the "What it looks like" section of https://microshed.org/microshed-testing/ but don't include the rest of the section after the second code example - that's too much detail for here. Then remove the code comments from the code example and instead use them in an explanation after the second code example to briefly explain what the integration test (second code snippet) is testing for and how it does it. ie move the code comments out of the code example and into the text of the topic.

If you like, you can use the 'call-out' capability of asciidoc to add markers in the code example so that it's easier to refer to specific lines from the text (https://asciidoctor.org/docs/user-manual/#callouts - like Charlotte's used in the first code example here: https://github.com/OpenLiberty/docs/blob/master/ref/config/serverConfiguration.adoc, which you can see here https://openliberty.io/docs/ref/config/), but you don't have to if it works just to describe it in ordinary text.

Then provide a link to the MicroShed Testing guide to learn more how to use it. And a link to the MicroShed Testing website.

[ManasiGandhi]

Draft link https://draft-openlibertyio.mybluemix.net/docs/ref/general/#microshed.html

[lauracowen]

• "unit tests, which test each microservice as an individual unit" - I don't think this is true. A microservice is a web service. A unit test would be lower level than the whole web service - more like individual bits of code within the web service. Andy will be able to clarify the definition of each though.
• "With faster development cycles and limited time available to developers, it’s not always feasible to run integrated tests." - this may be true but it reads as if we're recommending that that is what should happen. I think you can drop the last part of the sentence ("it's not always feasible") and then join the bit before it with the next sentence. But double-check that next sentence as I'm not sure that "test a few methods at a time" is a reason why they'd run them, and also "analyze your application better" is a bit vague.
• Don't include the "or dev-prod parity" bit, it's not necessary. Just use the full spelling everywhere. Or, if you're alluding to the term used by the 12-factor app website, that's fine but make sure it matches exactly (ie "dev/prod parity", not "dev-prod parity").
• "maven" -> "Maven"
• "Containers are increasingly being used, specifically in a microservices environment. Currently, many developers run containers in production." This doesn't quite make sense. Containers are used to deploy apps to the cloud (not specifically microservices). Developers don't do anything in production. Have a quick read of https://openliberty.io/guides/containerize.html to get a feel for how they're used. If there's useful text in there, you can copy it as it's our copyright. Ditto AndyG's MicroShed.org website (though I don't think he has so much in-depth explanation there).
• "using the same container that is used in production" - not exactly, it's using the same environment as in production (by using containers).
• In the first code example, remove all the comments from the code snippet (currently they're displaying alongside the code). Then after the example, use those comments to explain what the example shows.
• Can you get AndyG to do a review of it now there's a fair amount of change to it? Get him to check the assertions being made in some of the explanations.

[ManasiGandhi]

Andrew's comment "so the section "Why integration testing" is still not very convincing -- it's giving more reasons why NOT to use integration testing than it is supporting integration testing" I worked on it

[ManasiGandhi]

@lauracowen Here is the link to the microshed doc after SME review. Can you review it please? https://draft-openlibertyio.mybluemix.net/docs/ref/general/#microshed.html

[ManasiGandhi]

@chirp1 Here is the link to the microshed doc after SME review. Can you review it please? https://draft-openlibertyio.mybluemix.net/docs/ref/general/#microshed.html

[ManasiGandhi]

@dmuelle Can you do a peer review of this Microshed doc draft https://draft-openlibertyio.mybluemix.net/docs/ref/general/#microshed.html

[chirp1]

@Manasi @dmuelle Hi Manasi, I took a quick look at your topic. Before you have David review, would you go carefully through your topic and make additional changes? You can follow directions in various places, including, but not limited to, these places:

• The O box note on style: https://ibm.ent.box.com/notes/608241871659?s=5q0cv39fsz1xa6bxjf1dqzvtgc16z87u
• The cheat sheet on the wiki: https://apps.na.collabserv.com/wikis/home?lang=en-us#!/wiki/W93fb765ee31c_4aa7_98f6_a02c0f1a2ebf/page/Peer%20review%20cheat%20sheet , which also includes a link to the style guide.

Also, rerun Acrolinx and fix various issues that the tool mentions. Some things you can leave as is such as Java, twelve-factor, dev/prod, methodology, /myservice, NotFoundException.class, and ->. Fix the rest. In some cases, you might need to talk with the developer as to new wording. For example, for the word invoke, you might replace it with different words, depending on the occurrence.

[dmuelle]

peer review

5/1

intro

MicroShed Testing framework analyzes your application from outside the Docker container without accessing the application internals. I don't think you need "framework" iAfter Microshed testing. It seems awkward and also a little confusing since in the previous sentence, you identify microshed as a java library, resulting in two different definitions in back-to-back sentences.

Integration tests are more comprehensive than unit tests. However, integration tests can be more complicated and take longer to run.

I think this sentence should be in the next section. Instead you could have a brief paragraph that explains the benefit of testing from outside the docker container, ie what problem microshed solves.

Why integration testing

Integration tests assess multiple test classes and components, but take longer and can be complicated to set up and configure. You explain what integration tests are, but not unit tests, so the comparison here is not clear.

With shorter development cycles and limited time available, developers often run unit tests because they are easier and faster. instead of "easier", which acrolinx flags, maybe "less complex and faster to run than integration tests" ?

MicroShed Testing framework streamlines your integration tests with the Testcontainers library for a better workflow. In the shortdesc, Microshed isn a library and Testconainers is a framework. Here, they are reversed. I don't think you need framework here, but be consistent in how you refer to testcontainers. Also- "better" is unclear- better how?, maybe "more efficient" ?

Development-production parity

The application might work on your computer but not in production. I don't think this sentence adds anything that's not being said by the sentences before and after it, I'd recommend cutting it

Using MicroShed Testing

"Using" is indistinct- "Writing integration tests with Microshed Testing" might be more specific?

I think the introductory paragraph here can be reworked to explain how Microshed implements testcontainers to support dev/prod parity in testing. As is, it mainly talks about benefits of containers, which is not the main idea of this section. Avoid using "leverage" as a verb.

I think the code example should be a single block, with the description in a paragraph right after. You might have to rework the description a bit to get it to read coherently, but not much.

Make sure to put the text references to annotations (@RESTClient etc) in monospace

[Manasi]

Tagging @ManasiGandhi

[ManasiGandhi]

Andrew's review comments in Slack "hi Manasi, there is a broken link in the "Development-production partiy" section here: ... factors in the link:https://12factor.net/ [twelve-factor app], a methodology ... but other than that it looks good now"

[ManasiGandhi]

@lauracowen Can you review this topic?

https://draft-openlibertyio.mybluemix.net/docs/ref/general/#microshed.html

[lauracowen]

That's great! Thank you. :)

A couple of minor points but otherwise it's almost there:

• "MicroShed Testing streamlines your integration tests with the Testcontainers framework for an efficient workflow." - can you insert this sentence "MicroShed Testing makes it easier to write and run integration tests for your applications." (or similar) before the existing last sentence in that paragraph? It's a really nice paragraph and you've shown what the problem is currently but then you don't really provide the payoff - it just leaves it to the reader to work out that MicroShed Testing makes things better (the sentence about streamlining is a little marketing-y but would be fine with a more concrete sentence before it).
• The third (@RESTClient....) and fourth (Person bob...) examples look like they've been split in the middle when I think it should just be a blank line in the example, and I think there should be more syntax highlighting showing. Are you using the proper syntax highlighting tagging and marking it as Java? Talk to Charlotte or David if you need examples.
• I think this sentence should have more highlighting in it to show what are literal values and what's the sentence:

  which triggers the PersonService#createPerson endpoint and returns the generated ID Long bobId = personSvc.createPerson("Bob", 24); The sentence before the final example also probably needs some highlighting around the -1? Also, I think that sentence and the one before the final example don't actually make complete sense as sentences currently. @chirp1 might have some suggestions. I'm guessing Andy provided them as-is but I think they need to use less short-hand; eg "...to get a person with an ID of -1." maybe? Check with Andy that the meaning isn't changed though.

Let me know when you're done and I'll re-review it quickly. Thanks

[lauracowen]

• I think the second paragraph is just repeating what the first paragraph has already said. But the second paragraph is slightly clearer. Let's collapse them together and make a single paragraph that focuses on the value to the user rather than how the technology works: "MicroShed Testing helps you to write true-to-production integration tests for your applications. The tests are run against the same image that will be run in production to ensure that your application is being tested in the same way throughout the development process." If you want to also include the sentence (with its links) "MicroShed Testing uses the Testcontainers framework to analyze your application from outside the Docker container without accessing the application internals.", you need to add a bit to it saying why that matters. That could make a second paragraph then if you like, or just tag it on the end of the first paragraph.
• Can you change the heading "Development-production parity" to "Development and production parity". Then start the section with "Development and production parity (dev/prod parity) is one of the...etc" and make "dev/prod parity" into a link to https://12factor.net/dev-prod-parity.
• Can you change "Java EE" to "Jakarta EE" (wherever it's mentioned).
• On first mention of "Jakarta EE", link the words to https://jakarta.ee/
• There's still a white space gap half-way through the example Java that starts Person bob = ..... It looks like it should be a single code example?
• The code examples are still missing syntax highlighting. Every code snippet needs to have the language specified so that the text is in different colours.
• I don't think the text describing the code snippets is in the right places - it reads oddly. And the first sentence doesn't make sense.

• As David said above, the code example needs to be less fragmented. It doesn't really make sense as it is and I don't think it's very useful. @aguibert - please can you verify that what I'm about to type is useful to understanding the benefits of using MicroShed Testing? We're not trying to instruct here - we have the guide for that. We're trying to illustrate the topic that is introducing the concept and value of using MicroShed Testing (any other suggestions?).

  • Remove all the current example code snippets and their explanations in the "Writing integration tests..." section.
  • Instead, provide this example test method (from MicroShed.org):

    
    import org.junit.jupiter.api.Test;
    // ...

  @Test public void testGetPerson() { // This invokes an HTTP POST request to the running container, which triggers // the PersonService#createPerson endpoint and returns the generated ID Long bobId = personSvc.createPerson("Bob", 24);

  // Using the generated ID, invoke an HTTP GET request to read the record we just created
  // The JSON response will be automatically converted to a 'Person' object using JSON-B 
  Person bob = personSvc.getPerson(bobId);
  
  assertEquals("Bob", bob.name);
  assertEquals(24, bob.age);
  assertNotNull(bob.id);

  }

• But remove the four lines of comments that are in the middle of the example and, instead, create a short paragraph after the example that describes what the example does. The only reason for describing the example code is to show that it's easy to write simple tests if you're using MicroShed Testing.
• Maybe add a final sentence or two afterwards that summarises the value to the developer of using MicroShed Testing so that the topic doesn't just end abruptly and it's clear to the reader what they've learnt from reading this topic.

[aguibert]

yes that sounds reasonable @lauracowen, but for the code example we're going to show I think we need to give a bit more context than just the test method itself. Part of the value of Microshed Testing is the simplicity of setup, and if we just show the reader the test method we're missing out on an opportunity to say "see, this is all it takes"

For the code example I would suggest the code sample from https://microshed.org/microshed-testing/

@MicroShedTest
public class BasicJAXRSServiceTest {

    @Container
    public static ApplicationContainer app = new ApplicationContainer()
                    .withAppContextRoot("/myservice");

    @RESTClient
    public static PersonService personSvc;

    @Test
    public void testGetPerson() {
        // This invokes an HTTP POST request to the running container, which triggers
        // the PersonService#createPerson endpoint and returns the generated ID
        Long bobId = personSvc.createPerson("Bob", 24);

        // Using the generated ID, invoke an HTTP GET request to read the record we just created
        // The JSON response will be automatically converted to a 'Person' object using JSON-B 
        Person bob = personSvc.getPerson(bobId);

        assertEquals("Bob", bob.name);
        assertEquals(24, bob.age);
        assertNotNull(bob.id);
    }
}

[lauracowen]

@aguibert Great, thanks. That's helpful. @ManasiGandhi Okay, what I said in the comment above but use the code example that Andy gives in his comment instead of the one I provided. However, still remove the comments etc (but keep the code example as a single code snippet and put explanation below the whole thing).

[lauracowen]

Thanks. Can you remove the comments from the code snippet (so that the code snippet takes up fewer lines)? Then I think we're done.

[ManasiGandhi]

@lauracowen Removed the comments https://draft-openlibertyio.mybluemix.net/docs/ref/general/#microshed.html

[lauracowen]

Great, thanks. I'm going to sign it off now.

[chirp1]

Hi Mansi,

• Would you go back to my April 29 comment in this note and follow my instructions there?
  • Also, make title changes as appropriate based on this issue: https://github.com/OpenLiberty/docs/issues/1743.

If you have any questions, let me know.

[ManasiGandhi]

@chirp1 updated draft link https://draft-openlibertyio.mybluemix.net/docs/20.0.0.9/integration-testing.html

[chirp1]

Hi Manasi,

I think you did a nice job on the topic! I see a various things that could use a little sprucing:

• Avoid links in the introductory paragraph.

• In the opening paragraph you say true-to-production for Microshed testing, but later you say "similar to production" in "MicroShed Testing helps achieve development and production parity by testing the application in the environment similar to production." and "Microshed Testing is a Java library for MicroProfile and Jakarta EE developers to test their applications in an environment similar to production. ". Rewrite so that you are consistent with your terms.

• Having a link to a blog post on test containers at https://openliberty.io/blog/2019/03/27/integration-testing-with-testcontainers.html seems disorganized. We can't decide whether we want pertinent information in a topic or a blog post. My thought is that the blog post should be moved into a topic and the blog post redirected to the topic. Then, link from your topic to the topic about test containers instead of the blog.

• For the "Why integration testing" section, you say "....components, but take longer to set up and configure.". What does it take longer than?.

• For "Alternately, unit tests are shorter....", "Alternately" doesn't seem quite the right word to use. Although I see from google results that in some cases "alternately" is used in the US, "alternately" is not really the correct word to use in formal grammar for this particular sentence. Do some research on the use of the word alternately, and make changes as needed.

• I think the "Why integration testing" doesn't quite match the intent of the paragraph. I think what needs to be said is specifically about true-to-production integration tests, not integration tests in general, which is what the title of the section implies. The title might not even be needed. The discussion in the first two paragraphs could just flow into what you are covering in the "Why integration testing" section. But I think a point in the paragraph is a bit off even if the title for the section were removed. The section seems to be making a case for doing integration testing over unit testing and then mentions Microshed testing to accomplish integration testing. I think the paragraph should more clearly state that the user wants to not only do integration testing, but true-to-production integration testing through Microshed testing. Your paragraph does not really say this last sentence. It makes the user figure it out. Would you rewrite the paragraph so that the point is clearer and more crisply written?

• Change "...the twelve-factor app, a methodology ..." to "... the twelve-factor app, which is a methodology ...". <= Don't leave out "which is" or "that is" type of phrases as the phrases are useful for translators and non-English speakers.

• For "For example, you might use a local Maven build in development ", add to the sentence to explain why you might use a local Maven build. I think you could add about four words, for example, to explain why.

• Change "...the application in the environment similar to production." to "... the application in an environment similar to production.".

• You have at least one term in "Write integration tests with Microshed Testing" that needs a noun after the term.

• Definite or indefinite articles are missing throughout the topic before various nouns or noun phrases. Add them in where appropriate.

• For "...looks something like...", get rid of the extra word.

• Review the Peer review cheat sheet, particularly for "this, these, and those" and make corrections as appropriate.

• Change "ID -1, which " to "the -1 ID, which " <= Put the noun (ID) after -1.

• For "...to get a person with the -1 ID, which ...", "get a person" seems odd. I don't think a person is actually gotten. Would you rewrite the sentence?

• The wording for the "See also" section is in flux. I asked David/Charlotte to update the OL style info with an example or a sentence that is a template. Also, I asked them to change the wording so that it doesn't use "check out".

[ManasiGandhi]

@chirp1 Thanks for your review comments. I worked on your edit suggestions. You can view the changes here https://draft-openlibertyio.mybluemix.net/docs/20.0.0.9/integration-testing.html

• [x] Avoid links in the introductory paragraph.

• [x] In the opening paragraph you say true-to-production for Microshed testing, but later you say "similar to production" in "MicroShed Testing helps achieve development and production parity by testing the application in the environment similar to production." and "Microshed Testing is a Java library for MicroProfile and Jakarta EE developers to test their applications in an environment similar to production. ". Rewrite so that you are consistent with your terms.

• [x] Having a link to a blog post on test containers at https://openliberty.io/blog/2019/03/27/integration-testing-with-testcontainers.html seems disorganized. We can't decide whether we want pertinent information in a topic or a blog post. My thought is that the blog post should be moved into a topic and the blog post redirected to the topic. Then, link from your topic to the topic about test containers instead of the blog.

• [x] For the "Why integration testing" section, you say "....components, but take longer to set up and configure.". What does it take longer than?.

• [x] For "Alternately, unit tests are shorter....", "Alternately" doesn't seem quite the right word to use. Although I see from google results that in some cases "alternately" is used in the US, "alternately" is not really the correct word to use in formal grammar for this particular sentence. Do some research on the use of the word alternately, and make changes as needed.

• [x] I think the "Why integration testing" doesn't quite match the intent of the paragraph. I think what needs to be said is specifically about true-to-production integration tests, not integration tests in general, which is what the title of the section implies. The title might not even be needed. The discussion in the first two paragraphs could just flow into what you are covering in the "Why integration testing" section. But I think a point in the paragraph is a bit off even if the title for the section were removed. The section seems to be making a case for doing integration testing over unit testing and then mentions Microshed testing to accomplish integration testing. I think the paragraph should more clearly state that the user wants to not only do integration testing, but true-to-production integration testing through Microshed testing. Your paragraph does not really say this last sentence. It makes the user figure it out. Would you rewrite the paragraph so that the point is clearer and more crisply written?

• [x] Change "...the twelve-factor app, a methodology ..." to "... the twelve-factor app, which is a methodology ...". <= Don't leave out "which is" or "that is" type of phrases as the phrases are useful for translators and non-English speakers.

• [x] For "For example, you might use a local Maven build in development ", add to the sentence to explain why you might use a local Maven build. I think you could add about four words, for example, to explain why.

• [x] Change "...the application in the environment similar to production." to "... the application in an environment similar to production.".

• [x] You have at least one term in "Write integration tests with Microshed Testing" that needs a noun after the term.

• [x] Definite or indefinite articles are missing throughout the topic before various nouns or noun phrases. Add them in where appropriate.

• [x] For "...looks something like...", get rid of the extra word.

• [x] Review the Peer review cheat sheet, particularly for "this, these, and those" and make corrections as appropriate.

• [x] Change "ID -1, which " to "the -1 ID, which " <= Put the noun (ID) after -1.

• [x] For "...to get a person with the -1 ID, which ...", "get a person" seems odd. I don't think a person is actually gotten. Would you rewrite the sentence?

• [x] The wording for the "See also" section is in flux. I asked David/Charlotte to update the OL style info with an example or a sentence that is a template. Also, I asked them to change the wording so that it doesn't use "check out".

[chirp1]

Hi Manasi, based on our slack just now, would you investigate to do about the blog post on test containers?

[ManasiGandhi]

Hi Karen. I read through the Testcontainers blogpost https://openliberty.io/blog/2019/03/27/integration-testing-with-testcontainers.html and slacked Andrew. He said that the blogpost is not relevant to the topic and that it is an early precursor to Microshed.

[chirp1]

Hi Manasi, I'm returning this issue so that you make your terms consistent. See my second bullet and the peer review cheat sheet. You seem to have made the two terms more concrete by adding "or integration tests that test your application in an environment similar to production." to the intro instead of making your terms consistent.

[ManasiGandhi]

@chirp1 I updated the draft https://draft-openlibertyio.mybluemix.net/docs/20.0.0.9/integration-testing.html.

[chirp1]

Hi Manasi,

• This one looks like it still needs to be done: For the "Why integration testing" section, you say "....components, but take longer to set up and configure.". What does it take longer than?. (I slacked Manasi. She is making updates.)
• You still seem to have "true-to-production" and "similar to production". As mentioned in the peer review cheat sheet, don't say a term two different ways. Use one term consistently.
• In looking at the "Write integration tests with the Microshed Testing library" title more, how about if you use a gerund for "Write" instead?
• I see that you updated wording for "person" to "The @Test annotation sends a HTTP GET request to find a Person with the -1 ID, which does not exist.". The wording still seems a little odd because the current wording seems to be saying that a get request is finding a person. I don't think get requests find people.
• I still spot missing definite/indefinite articles. Review the article and add them in where appropriate.
• For "The JSON response automatically converts to a Person object by using JSON-B token.", is the JSON response automatically converted to a Person object, or does the JSON response automatically convert something? Would you rewrite the sentence to make clear what is going on?
• You still have at least one term without a noun after it.

If you want to discuss any of these points, feel free to slack me.

[ManasiGandhi]

@chirp1 I worked on your edit suggestions:

• [x] This one looks like it still needs to be done: For the "Why integration testing" section, you say "....components, but take longer to set up and configure.". What does it take longer than?. (I slacked Manasi. She is making updates.)

• [x] You still seem to have "true-to-production" and "similar to production". As mentioned in the peer review cheat sheet, don't say a term two different ways. Use one term consistently.

• [x] In looking at the "Write integration tests with the Microshed Testing library" title more, how about if you use a gerund for "Write" instead?

• [x] I see that you updated wording for "person" to "The @test annotation sends a HTTP GET request to find a Person with the -1 ID, which does not exist.". The wording still seems a little odd because the current wording seems to be saying that a get request is finding a person. I don't think get requests find people.

• [x] I still spot missing definite/indefinite articles. Review the article and add them in where appropriate.

• [x] For "The JSON response automatically converts to a Person object by using JSON-B token.", is the JSON response automatically converted to a Person object, or does the JSON response automatically convert something? Would you rewrite the sentence to make clear what is going on?

• [x] You still have at least one term without a noun after it.

[chirp1]

Hi! We're almost done! Here are my latest comments:

• Change "... helps you write integration tests for your application ..." back to "... helps you write true-to-production integration tests for your application ...".
• For "... configure, as compared to unit tests.", reword to write more concisely. Specifically, reword the phrase by substituting "than" for "as compared to" so that it reads as "... configure than unit tests."
• Change "...often choose to run unit tests." to "...often run unit tests.".
• Change "MicroShed Testing helps to write and run..." to "MicroShed Testing helps you write and run...".
• Remove the stray comma in "Development and production parity, is one...".
• In the topic, you have been discussing applications in containers and deploying applications, but then you switch to microservices when you say "You can deploy your microservices in different environments with containers.". How about if you use "applications" instead of "microservices" to be consistent?
• Remove "the" in "...for the MicroProfile and Jakarta EE developers...".
• In multiple places you switched to ".... a HTTP...." from the correct ".... an HTTP....". Review when to use "a" versus "an" and correct.
• You still have at least one term without a noun after it. Review "PersonService" in "...proxy of the PersonService, which..." and add the appropriate noun after "PersonService". Check with your developer as necessary.

[ManasiGandhi]

@chirp1 I worked on your review comments.

• [x] Change "... helps you write integration tests for your application ..." back to "... helps you write true-to-production integration tests for your application ...".

• [x] For "... configure, as compared to unit tests.", reword to write more concisely. Specifically, reword the phrase by substituting "than" for "as compared to" so that it reads as "... configure than unit tests."

• [x] Change "...often choose to run unit tests." to "...often run unit tests.".

• [x] Change "MicroShed Testing helps to write and run..." to "MicroShed Testing helps you write and run...".

• [x] Remove the stray comma in "Development and production parity, is one...".

• [x] In the topic, you have been discussing applications in containers and deploying applications, but then you switch to microservices when you say "You can deploy your microservices in different environments with containers.". How about if you use "applications" instead of "microservices" to be consistent?

• [x] Remove "the" in "...for the MicroProfile and Jakarta EE developers...".

• [x] In multiple places you switched to ".... a HTTP...." from the correct ".... an HTTP....". Review when to use "a" versus "an" and correct.

• [x] You still have at least one term without a noun after it. Review "PersonService" in "...proxy of the PersonService, which..." and add the appropriate noun after "PersonService". Check with your developer as necessary.

[chirp1]

One last change:

• Remove "the" from "...to support the development and production parity in testing.".

[ManasiGandhi]

@chirp1 I worked on your review comment.

• [x] Remove "the" from "...to support the development and production parity in testing.".

[chirp1]

The update looks good. We are done. Closing.