Should tests perform a single assertion, or are multiple related assertions acceptable

Assume a client is making a request to an API endpoint that returns a JSON response where the structure and data change depending on whether the request was successful or not. Possible responses may look as follows:

Scenario with a success response

{   "status": XXX,   "data": [{     ...   }] } 

Scenario with a failure response

{   "status": XXX,   "errors": [{     ...   }] } 

Example of test scenarios for the above would be:

  • Assert the expected status code
  • Assert the expected JSON structure
  • Assert the expected JSON data

When performing tests where you have more than one assertion you can perform, is it recommended to provide a single test for each assertion, or group the assertions into a single test?

are following assertions about linux load and tomcat right?

I am looking to understand precisely how to use the load average and cpu usage on a Red hat machine that hosts a Tomcat 8 only. After looking on the net, I concluded the following assertions. Are the assertions right ? I am deeply sure of the first one since it comes from official Tomcat documentation. And I am confused about which processes could be in uninterruptible sleep.

1) Tomcat uses a thread to process a request, the maximum number of used threads is defined by Tomcat configuration ( see Tomcat documentation )

2) Oracle JVM works with native threads only since JRE 1.3 ( See JVM and threads I did not find an Oracle reference for this point)

3) Linux’s run queue contains processes and threads (id native threads) the same way ( See Linux Load Averages: Solving the Mystery and Wikipedia )

4) Load average provides the average number of process/threads in the run queue ( See Linux Journal )

5) On a Linux machine running a Tomcat only, the load average provides almost the average number of requests.

6) On Linux the load average count process/threads in state running, runnable, and uninterruptible sleep ( See Linux Journal )

7) Process/threads in uninterruptible sleep are waiting for disks I/O, non interruptible locks, network I/O ( See Redhat documenationt that includes network I/O and Linux Load Averages: Solving the Mystery that does not include network I/0 )

The point 7 is not coherent with the reference See Linux Journal that says that “In fact, it is precisely the CPU load that is measured, because load averages do not include any processes or threads waiting on I/O, networking, databases or anything else not demanding the CPU. “.

I understood that if a process reads swap it is in uninterruptible sleep but if it reads a file on internal disk, nfs folder or a SAN bay, is it in uninterruptible sleep ? Red hat documentation listed network, if a process requests a resource on the network is it in uninterruptible sleep ?

Should there be assertions in release builds

The default behavior of assert in C++ is to do nothing in release builds. I presume this is done for performance reasons and maybe to prevent users from seeing nasty error messages.

However, I’d argue that those situations where an assert would have fired but was disabled are even more troublesome because the application will then probably crash in an even worse way down the line because some invariant was broken.

Additionally, the performance argument for me only counts when it is a measurable problem. Most asserts in my code aren’t much more complex than

assert(ptr != nullptr); 

which will have small impact on most code.

This leads me to the question: Should assertions (meaning the concept, not the specific implementation) be active in release builds? Why (not)?

Please note that this question is not about how to enable asserts in release builds (like #undef _NDEBUG or using a self defined assert implementation). Furthermore, it is not about enabling asserts in third party/standard library code but in code controlled by me.