Acceptance tests are tests written by the business in order to verify that the requirements are being met. Typically they are specified by, and written by, business analysts and QA.
Acceptance tests can sometimes go through the front-end using tools like Selenium; but this is usually a bad idea because the front-end is very volatile and such tests are therefore fragile. It is better for those tests to access the business rules independently of the front end, using an API tester like FitNesse, Cucumber, or Specflow. These tools use business friendly input syntax, but typically bypass the front end.
Integration tests are very technical. They are specified by architects and tech-leads. The goal is to test the plumbing of the system, that communication pathways work as desired, and all the components dance properly. Such tests are often written in code as opposed to an API or front-end testing tool. Business people and QA are typically not technical enough to specify such tests.
As a solo developer you will seldom need more than unit tests unless you have a customer who is familiar with API testing tools like Cucumber.
>From: lechiffre<-KoalaSat at 02/28/23 10:41:08 on wss://relay.damus.io
>---------------
>I'm a solo developer, and I live by unit tests and integration tests. How do integration tests differ from the acceptance tests? Are acceptance tests principally browser/frontend/ui automation?
unclebobmartin /
npub19m…njnft
2023-02-28 16:49:18
in reply to nevent1q…aamj
Author Public Key
npub19mun7qwdyjf7qs3456u8kyxncjn5u2n7klpu4utgy68k4aenzj6synjnftPublished at
2023-02-28 16:49:18Event JSON
{
"id": "000089cac63dae4f016c3db43dd46e27fa0e6702b77183044cb6d55e15891c2e",
"pubkey": "2ef93f01cd2493e04235a6b87b10d3c4a74e2a7eb7c3caf168268f6af73314b5",
"created_at": 1677602958,
"kind": 1,
"tags": [
[
"e",
"00001644e9c9938bfdbdaee9f975fd427b600ef4aa313db076a5c6b2b8520826",
"",
"root"
],
[
"e",
"5e71413e1cecfdfa4ecdc72efc15acf3062b942204b7241efc73a0e4f6ce24a5",
"",
"reply"
],
[
"p",
"d7b76d02c758a62a505e03bd5f5049aaee4e7e36283d273c7f6798912692df2b"
],
[
"client",
"more-speech - 2023-02-21T15:39"
],
[
"nonce",
"26953",
"16"
]
],
"content": "Acceptance tests are tests written by the business in order to verify that the requirements are being met. Typically they are specified by, and written by, business analysts and QA. \n\nAcceptance tests can sometimes go through the front-end using tools like Selenium; but this is usually a bad idea because the front-end is very volatile and such tests are therefore fragile. It is better for those tests to access the business rules independently of the front end, using an API tester like FitNesse, Cucumber, or Specflow. These tools use business friendly input syntax, but typically bypass the front end.\n\nIntegration tests are very technical. They are specified by architects and tech-leads. The goal is to test the plumbing of the system, that communication pathways work as desired, and all the components dance properly. Such tests are often written in code as opposed to an API or front-end testing tool. Business people and QA are typically not technical enough to specify such tests. \n\nAs a solo developer you will seldom need more than unit tests unless you have a customer who is familiar with API testing tools like Cucumber.\n\n\n\u003eFrom: lechiffre\u003c-KoalaSat at 02/28/23 10:41:08 on wss://relay.damus.io\n\u003e---------------\n\u003eI'm a solo developer, and I live by unit tests and integration tests. How do integration tests differ from the acceptance tests? Are acceptance tests principally browser/frontend/ui automation?",
"sig": "0bf4ba07e612a3bace4fd0a5004ad3694effe0a727d17c710df54821e6adc63577efbd52d12f343544ac39c4eca96c72dcef445d47844d51e1f485d7e73097a2"
}