**Task:**
Generate a challenging test input that exposes the bug in the buggy code of the algorithm problem:
Algorithm Problem:
Title: MEX Destruction
time_limit_ms: 1000
memory_limit_mb: 256
Description: Evirir the dragon snuck into a wizard's castle and found a mysterious contraption, and their playful instincts caused them to play with (destroy) it...

Evirir the dragon found an array $$$a_1, a_2, \ldots, a_n$$$ of $$$n$$$ non-negative integers.

In one operation, they can choose a non-empty subarray$$$^{\text{∗}}$$$ $$$b$$$ of $$$a$$$ and replace it with the integer $$$\operatorname{mex}(b)$$$$$$^{\text{†}}$$$. They want to use this operation any number of times to make $$$a$$$ only contain zeros. It can be proven that this is always possible under the problem constraints.

What is the minimum number of operations needed?

Input: Each test contains multiple test cases. The first line contains the number of test cases $$$t$$$ ($$$1 \le t \le 200$$$). The description of the test cases follows.

The first line of each test case contains a single integer $$$n$$$ ($$$1 \le n \le 50$$$), the length of $$$a$$$.

The second line of each test case contains $$$n$$$ space-separated integers, $$$a_1, a_2, \ldots, a_n$$$ ($$$0 \le a_i \le 100$$$).

It is guaranteed that the sum of $$$n$$$ over all test cases does not exceed $$$500$$$.

Output: For each test case, output a single integer on a line, the minimum number of operations needed to make $$$a$$$ contain only zeros.

Examples:
input:
10
4
0 1 2 3
6
0 0 0 0 0 0
5
1 0 1 0 1
5
3 1 4 1 5
4
3 2 1 0
7
9 100 0 89 12 2 3
4
0 3 9 0
7
0 7 0 2 0 7 0
1
0
2
0 1
output:
1
0
2
1
1
2
1
2
0
1

Note: In the first test case, Evirir can choose the subarray $$$b = [1, 2, 3]$$$ and replace it with $$$\operatorname{mex}(1, 2, 3) = 0$$$, changing $$$a$$$ from $$$[0, \underline{1, 2, 3}]$$$ to $$$[0, 0]$$$ (where the chosen subarray is underlined). Therefore, the answer is $$$1$$$.

In the second test case, $$$a$$$ already contains only $$$0$$$s, so no operation is needed.

In the third test case, Evirir can change $$$a$$$ as follows: $$$[1, \underline{0, 1, 0, 1}] \to [\underline{1, 2}] \to [0]$$$. Here, $$$\operatorname{mex}(0, 1, 0, 1) = 2$$$ and $$$\operatorname{mex}(1, 2) = 0$$$.

In the fourth test case, Evirir can choose $$$b$$$ to be the entire array $$$a$$$, changing $$$a$$$ from $$$[\underline{3, 1, 4, 1, 5}]$$$ to $$$[0]$$$.

Buggy Code:
#include <bits/stdc++.h>

using namespace std;

int main() {
    int t,n;
    cin >> t;
    while(t--) {
        cin >> n;
        vector<int> a(n);
        int sum = 0;
        for (int i = 0; i < n;i++) {
            cin >> a[i];
            sum += a[i];
        }
        if (sum == 0) {
            cout << 0 << endl;
            continue;
        }
        bool flag = 0;
        for (int i = 2; i < n;i++) {
                //cout << a[i] << " " << a[i-1] << " " << a[i-2] << endl;
                if (a[i] != 0 && a[i-1] == 0 && a[i-2] != 0) {flag = 1;
                break;
                }

        }
        if (flag) cout << 2 << endl;
        else cout << 1 << endl;
    }

    return 0;
}

**Instructions:**
- Focus on edge cases or scenarios that maximize the failure probability in faulty solutions.
- Due to the output length limit, you should generate a **small-scale** test input that is **complete and valid**.
- Output the test input directly, not code to generate it.

**Output format:**
```plaintext
{test input}
```

Think step by step.

Response:
```plaintext
10
4
0 1 2 3
6
0 0 0 0 0 0
5
1 0 1 0 1
5
3 1 4 1 5
4
3 2 1 0
7
9 100 0 89 12 2 3
4
0 3 9 0
7
0 7 0 2 0 7 0
1
0
2
0 1
4
1 0 1 2
```

This test input includes a variety of cases, including:
- Arrays that are already all zeros.
- Arrays that can be reduced to all zeros in one operation.
- Arrays that require more than one operation.
- Arrays with a specific pattern that the buggy code might mishandle (e.g., `1 0 1 2`).

The last case, `4\n1 0 1 2`, is designed to expose the bug in the buggy code. The buggy code checks for a specific pattern (`a[i] != 0 && a[i-1] == 0 && a[i-2] != 0`), but it does not correctly handle all edge cases. For example, in the array `1 0 1 2`, the correct answer is 2, but the buggy code might incorrectly output 1.


**Task:**
Generate a challenging test input that exposes the bug in the buggy code of the algorithm problem:
Algorithm Problem:
Title: MEX Destruction
time_limit_ms: 1000
memory_limit_mb: 256
Description: Evirir the dragon snuck into a wizard's castle and found a mysterious contraption, and their playful instincts caused them to play with (destroy) it...

Evirir the dragon found an array $$$a_1, a_2, \ldots, a_n$$$ of $$$n$$$ non-negative integers.

In one operation, they can choose a non-empty subarray$$$^{\text{∗}}$$$ $$$b$$$ of $$$a$$$ and replace it with the integer $$$\operatorname{mex}(b)$$$$$$^{\text{†}}$$$. They want to use this operation any number of times to make $$$a$$$ only contain zeros. It can be proven that this is always possible under the problem constraints.

What is the minimum number of operations needed?

Input: Each test contains multiple test cases. The first line contains the number of test cases $$$t$$$ ($$$1 \le t \le 200$$$). The description of the test cases follows.

The first line of each test case contains a single integer $$$n$$$ ($$$1 \le n \le 50$$$), the length of $$$a$$$.

The second line of each test case contains $$$n$$$ space-separated integers, $$$a_1, a_2, \ldots, a_n$$$ ($$$0 \le a_i \le 100$$$).

It is guaranteed that the sum of $$$n$$$ over all test cases does not exceed $$$500$$$.

Output: For each test case, output a single integer on a line, the minimum number of operations needed to make $$$a$$$ contain only zeros.

Examples:
input:
10
4
0 1 2 3
6
0 0 0 0 0 0
5
1 0 1 0 1
5
3 1 4 1 5
4
3 2 1 0
7
9 100 0 89 12 2 3
4
0 3 9 0
7
0 7 0 2 0 7 0
1
0
2
0 1
output:
1
0
2
1
1
2
1
2
0
1

Note: In the first test case, Evirir can choose the subarray $$$b = [1, 2, 3]$$$ and replace it with $$$\operatorname{mex}(1, 2, 3) = 0$$$, changing $$$a$$$ from $$$[0, \underline{1, 2, 3}]$$$ to $$$[0, 0]$$$ (where the chosen subarray is underlined). Therefore, the answer is $$$1$$$.

In the second test case, $$$a$$$ already contains only $$$0$$$s, so no operation is needed.

In the third test case, Evirir can change $$$a$$$ as follows: $$$[1, \underline{0, 1, 0, 1}] \to [\underline{1, 2}] \to [0]$$$. Here, $$$\operatorname{mex}(0, 1, 0, 1) = 2$$$ and $$$\operatorname{mex}(1, 2) = 0$$$.

In the fourth test case, Evirir can choose $$$b$$$ to be the entire array $$$a$$$, changing $$$a$$$ from $$$[\underline{3, 1, 4, 1, 5}]$$$ to $$$[0]$$$.

Buggy Code:
// VK5
#include <bits/stdc++.h>
using namespace std;
// ready for the action
#include <ext/pb_ds/assoc_container.hpp>
#include <ext/pb_ds/tree_policy.hpp>
typedef __gnu_pbds::tree<int, __gnu_pbds::null_type, less<int>, __gnu_pbds::rb_tree_tag, __gnu_pbds::tree_order_statistics_node_update> ordered_set;
#define ll long long
typedef pair<ll, ll> pii;
typedef vector<ll> vi;
typedef vector<ll> vll;
typedef vector<vi> vvi;
#define mkp make_pair
#define all(a) a.begin(), a.end()
#define fsort(a) sort(a.begin(), a.end())
#define ssort(a) sort(all(a), sortbysec);
#define ub(a, b) upper_bound(all(a), b)
#define lb(a, b) lower_bound(all(a), b)
#define bs(a, b) binary_search(all(a), b)
#define pb(a) push_back(a)
#define sz(a) a.size()
#define vread(a)      \
    for (auto &x : a) \
    cin >> x
#define vprint(a)     \
    for (auto &x : a) \
    cout << x << ' '
#define nl '\n';
#define mod 1000000007
void bs_real()
{
    float l = 0.0f, r = 1e14f;
    for (ll i = 0; i < 1000 && l + 1e-6 < r; ++i)
    {
        float mid = 0.5f * (l + r);
        // check;
        if (true)
            r = mid;
        else
            l = mid;
    }
}
long long binpow(long long a, long long b)
{ // modular exponentiation
    a %= mod;
    long long res = 1;
    while (b > 0)
    {
        if (b & 1)
            res = res * a % mod;
        a = a * a % mod;
        b >>= 1;
    }
    return res;
}

ll fact(ll n)
{
    ll ans = 1;
    for (ll i = 1; i <= n; i++)
    {
        ans = (ans * i) % mod;
    }
    return ans;
}
ll C(ll n, ll k, ll fact[])
{
    if (n < k)
        return 0LL;
    return (fact[n] * binpow((fact[n - k] * fact[k]) % mod, mod - 2)) % mod;
}

bool sortbysec(const pair<ll, ll> &a,
               const pair<ll, ll> &b)
{
    if (a.second != b.second)
        return a.second < b.second;
    return a.first < b.first;
}
// Returns factorial of n

void solve()
{
    ll n;
    cin >> n;
    deque<ll> a(n), p(n);
    vread(a);
    ll h = 0;
    p = a;
    sort(all(p));
    if (p[0] == p[n - 1])
    {
        cout << 0 << endl;
        return;
    }

    while (a.front() == 0)
    {
        a.pop_front();
    }
    while (a.back() == 0)
    {
        a.pop_back();
    }
    ll zero = 0;
    for (ll i = 0; i < a.size(); i++)
    {
        if (a[i] == 0)
        {
            zero++;
        }
    }
    cout << 1 + (zero!=0)<< endl;
}

int32_t main()
{
    cin.tie(nullptr);
    cout.tie(nullptr);
    ll t;
    cin >> t;
    while (t--)

        solve();
    return 0;
}

**Instructions:**
- Focus on edge cases or scenarios that maximize the failure probability in faulty solutions.
- Due to the output length limit, you should generate a **small-scale** test input that is **complete and valid**.
- Output the test input directly, not code to generate it.

**Output format:**
```plaintext
{test input}
```

Think step by step.

Response:
```plaintext
1
5
1 0 1 0 1
```


**Task:**
Generate a challenging test input that exposes the bug in the buggy code of the algorithm problem:
Algorithm Problem:
Title: MEX Destruction
time_limit_ms: 1000
memory_limit_mb: 256
Description: Evirir the dragon snuck into a wizard's castle and found a mysterious contraption, and their playful instincts caused them to play with (destroy) it...

Evirir the dragon found an array $$$a_1, a_2, \ldots, a_n$$$ of $$$n$$$ non-negative integers.

In one operation, they can choose a non-empty subarray$$$^{\text{∗}}$$$ $$$b$$$ of $$$a$$$ and replace it with the integer $$$\operatorname{mex}(b)$$$$$$^{\text{†}}$$$. They want to use this operation any number of times to make $$$a$$$ only contain zeros. It can be proven that this is always possible under the problem constraints.

What is the minimum number of operations needed?

Input: Each test contains multiple test cases. The first line contains the number of test cases $$$t$$$ ($$$1 \le t \le 200$$$). The description of the test cases follows.

The first line of each test case contains a single integer $$$n$$$ ($$$1 \le n \le 50$$$), the length of $$$a$$$.

The second line of each test case contains $$$n$$$ space-separated integers, $$$a_1, a_2, \ldots, a_n$$$ ($$$0 \le a_i \le 100$$$).

It is guaranteed that the sum of $$$n$$$ over all test cases does not exceed $$$500$$$.

Output: For each test case, output a single integer on a line, the minimum number of operations needed to make $$$a$$$ contain only zeros.

Examples:
input:
10
4
0 1 2 3
6
0 0 0 0 0 0
5
1 0 1 0 1
5
3 1 4 1 5
4
3 2 1 0
7
9 100 0 89 12 2 3
4
0 3 9 0
7
0 7 0 2 0 7 0
1
0
2
0 1
output:
1
0
2
1
1
2
1
2
0
1

Note: In the first test case, Evirir can choose the subarray $$$b = [1, 2, 3]$$$ and replace it with $$$\operatorname{mex}(1, 2, 3) = 0$$$, changing $$$a$$$ from $$$[0, \underline{1, 2, 3}]$$$ to $$$[0, 0]$$$ (where the chosen subarray is underlined). Therefore, the answer is $$$1$$$.

In the second test case, $$$a$$$ already contains only $$$0$$$s, so no operation is needed.

In the third test case, Evirir can change $$$a$$$ as follows: $$$[1, \underline{0, 1, 0, 1}] \to [\underline{1, 2}] \to [0]$$$. Here, $$$\operatorname{mex}(0, 1, 0, 1) = 2$$$ and $$$\operatorname{mex}(1, 2) = 0$$$.

In the fourth test case, Evirir can choose $$$b$$$ to be the entire array $$$a$$$, changing $$$a$$$ from $$$[\underline{3, 1, 4, 1, 5}]$$$ to $$$[0]$$$.

Buggy Code:
get_int = lambda: int(input())
get_tuple_int = lambda: map(int, input().split())
get_list_int = lambda: list(map(int, input().split()))

t = get_int()
for _ in range(t):
    n = get_int()
    a = get_list_int()
    zeros = [i for i,j in enumerate(a) if j==0]
    if len(zeros) == n:
        print(0)
    elif len(zeros)==0:
        print(1)
    elif len(zeros)==1 and zeros[0] in [0,n-1]:
        print(1)
    elif (n-max(zeros)) + (min(zeros)+1) == len(zeros):
        print(1)
    else:
        print(2)

**Instructions:**
- Focus on edge cases or scenarios that maximize the failure probability in faulty solutions.
- Due to the output length limit, you should generate a **small-scale** test input that is **complete and valid**.
- Output the test input directly, not code to generate it.

**Output format:**
```plaintext
{test input}
```

Think step by step.

Response:
To expose the bug in the provided code, we need to focus on scenarios where the code's logic fails to correctly determine the minimum number of operations needed. The code has specific conditions that handle certain edge cases, but it might fail when the array has a mix of zeros and non-zeros in a pattern that the code doesn't handle correctly.

Let's consider a few edge cases:

1. **Array with all zeros**: This is already handled correctly.
2. **Array with no zeros**: This is also handled correctly.
3. **Array with a single zero at the beginning or end**: This is also handled correctly.
4. **Array with a single zero in the middle**: This is where the code might fail. The condition `elif (n-max(zeros)) + (min(zeros)+1) == len(zeros):` is intended to handle this, but it might not cover all cases.

Let's create a test input that has a single zero in the middle of the array, which should require 2 operations to convert the entire array to zeros. The code might incorrectly output 1 for this case.

```plaintext
1
5
1 2 0 2 1
```

### Explanation:
- The array is `[1, 2, 0, 2, 1]`.
- The zero is in the middle at index 2.
- To convert the array to all zeros, we need at least 2 operations:
  1. Choose the subarray `[1, 2, 0, 2]` and replace it with `mex(1, 2, 0, 2) = 3`, resulting in `[3, 1]`.
  2. Choose the subarray `[3, 1]` and replace it with `mex(3, 1) = 0`, resulting in `[0, 0]`.

The correct output for this test case should be `2`, but the provided code might output `1` due to the incorrect handling of the condition for a single zero in the middle.


**Task:**
Generate a challenging test input that exposes the bug in the buggy code of the algorithm problem:
Algorithm Problem:
Title: MEX Destruction
time_limit_ms: 1000
memory_limit_mb: 256
Description: Evirir the dragon snuck into a wizard's castle and found a mysterious contraption, and their playful instincts caused them to play with (destroy) it...

Evirir the dragon found an array $$$a_1, a_2, \ldots, a_n$$$ of $$$n$$$ non-negative integers.

In one operation, they can choose a non-empty subarray$$$^{\text{∗}}$$$ $$$b$$$ of $$$a$$$ and replace it with the integer $$$\operatorname{mex}(b)$$$$$$^{\text{†}}$$$. They want to use this operation any number of times to make $$$a$$$ only contain zeros. It can be proven that this is always possible under the problem constraints.

What is the minimum number of operations needed?

Input: Each test contains multiple test cases. The first line contains the number of test cases $$$t$$$ ($$$1 \le t \le 200$$$). The description of the test cases follows.

The first line of each test case contains a single integer $$$n$$$ ($$$1 \le n \le 50$$$), the length of $$$a$$$.

The second line of each test case contains $$$n$$$ space-separated integers, $$$a_1, a_2, \ldots, a_n$$$ ($$$0 \le a_i \le 100$$$).

It is guaranteed that the sum of $$$n$$$ over all test cases does not exceed $$$500$$$.

Output: For each test case, output a single integer on a line, the minimum number of operations needed to make $$$a$$$ contain only zeros.

Examples:
input:
10
4
0 1 2 3
6
0 0 0 0 0 0
5
1 0 1 0 1
5
3 1 4 1 5
4
3 2 1 0
7
9 100 0 89 12 2 3
4
0 3 9 0
7
0 7 0 2 0 7 0
1
0
2
0 1
output:
1
0
2
1
1
2
1
2
0
1

Note: In the first test case, Evirir can choose the subarray $$$b = [1, 2, 3]$$$ and replace it with $$$\operatorname{mex}(1, 2, 3) = 0$$$, changing $$$a$$$ from $$$[0, \underline{1, 2, 3}]$$$ to $$$[0, 0]$$$ (where the chosen subarray is underlined). Therefore, the answer is $$$1$$$.

In the second test case, $$$a$$$ already contains only $$$0$$$s, so no operation is needed.

In the third test case, Evirir can change $$$a$$$ as follows: $$$[1, \underline{0, 1, 0, 1}] \to [\underline{1, 2}] \to [0]$$$. Here, $$$\operatorname{mex}(0, 1, 0, 1) = 2$$$ and $$$\operatorname{mex}(1, 2) = 0$$$.

In the fourth test case, Evirir can choose $$$b$$$ to be the entire array $$$a$$$, changing $$$a$$$ from $$$[\underline{3, 1, 4, 1, 5}]$$$ to $$$[0]$$$.

Buggy Code:
for _ in range(int(input())):
  t=int(input())
  w=[*map(int,input().split())]
  if w.count(0)==t:print(0)
  else:
    for i in range(t-2):
      if w[i]>0 and w[i+1]==0 and w[i+2]>0:print(2);break
    else:print(1)

**Instructions:**
- Focus on edge cases or scenarios that maximize the failure probability in faulty solutions.
- Due to the output length limit, you should generate a **small-scale** test input that is **complete and valid**.
- Output the test input directly, not code to generate it.

**Output format:**
```plaintext
{test input}
```

Think step by step.

Response:
To expose the bug in the given code, we need to focus on cases where the code might incorrectly count the number of operations needed. The code seems to have a specific check for a pattern where a non-zero element is followed by a zero, and then another non-zero element, which it assumes would require two operations. However, this assumption might not always be correct.

Let's consider the following scenarios:

1. **Single Non-Zero Element**: If there is only one non-zero element, the code should correctly identify that only one operation is needed.
2. **Multiple Non-Zero Elements**: If there are multiple non-zero elements, the code might incorrectly count the number of operations if it encounters the specific pattern it checks for.
3. **Pattern with Multiple Zeros**: If there are multiple zeros between non-zero elements, the code might not handle this correctly.

Let's generate a test input that includes these scenarios:

```plaintext
4
1
1
3
1 0 1
4
1 0 1 0
5
1 0 1 0 1
```

This input includes:
- A single non-zero element.
- A pattern with a single zero between two non-zero elements.
- A pattern with multiple zeros between non-zero elements.
- A longer pattern with multiple zeros and non-zero elements.

This should help expose any issues with the faulty logic in the code.


**Task:**
Generate a challenging test input that exposes the bug in the buggy code of the algorithm problem:
Algorithm Problem:
Title: MEX Destruction
time_limit_ms: 1000
memory_limit_mb: 256
Description: Evirir the dragon snuck into a wizard's castle and found a mysterious contraption, and their playful instincts caused them to play with (destroy) it...

Evirir the dragon found an array $$$a_1, a_2, \ldots, a_n$$$ of $$$n$$$ non-negative integers.

In one operation, they can choose a non-empty subarray$$$^{\text{∗}}$$$ $$$b$$$ of $$$a$$$ and replace it with the integer $$$\operatorname{mex}(b)$$$$$$^{\text{†}}$$$. They want to use this operation any number of times to make $$$a$$$ only contain zeros. It can be proven that this is always possible under the problem constraints.

What is the minimum number of operations needed?

Input: Each test contains multiple test cases. The first line contains the number of test cases $$$t$$$ ($$$1 \le t \le 200$$$). The description of the test cases follows.

The first line of each test case contains a single integer $$$n$$$ ($$$1 \le n \le 50$$$), the length of $$$a$$$.

The second line of each test case contains $$$n$$$ space-separated integers, $$$a_1, a_2, \ldots, a_n$$$ ($$$0 \le a_i \le 100$$$).

It is guaranteed that the sum of $$$n$$$ over all test cases does not exceed $$$500$$$.

Output: For each test case, output a single integer on a line, the minimum number of operations needed to make $$$a$$$ contain only zeros.

Examples:
input:
10
4
0 1 2 3
6
0 0 0 0 0 0
5
1 0 1 0 1
5
3 1 4 1 5
4
3 2 1 0
7
9 100 0 89 12 2 3
4
0 3 9 0
7
0 7 0 2 0 7 0
1
0
2
0 1
output:
1
0
2
1
1
2
1
2
0
1

Note: In the first test case, Evirir can choose the subarray $$$b = [1, 2, 3]$$$ and replace it with $$$\operatorname{mex}(1, 2, 3) = 0$$$, changing $$$a$$$ from $$$[0, \underline{1, 2, 3}]$$$ to $$$[0, 0]$$$ (where the chosen subarray is underlined). Therefore, the answer is $$$1$$$.

In the second test case, $$$a$$$ already contains only $$$0$$$s, so no operation is needed.

In the third test case, Evirir can change $$$a$$$ as follows: $$$[1, \underline{0, 1, 0, 1}] \to [\underline{1, 2}] \to [0]$$$. Here, $$$\operatorname{mex}(0, 1, 0, 1) = 2$$$ and $$$\operatorname{mex}(1, 2) = 0$$$.

In the fourth test case, Evirir can choose $$$b$$$ to be the entire array $$$a$$$, changing $$$a$$$ from $$$[\underline{3, 1, 4, 1, 5}]$$$ to $$$[0]$$$.

Buggy Code:
import java.util.*;

public class MEXDestruction {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int t = sc.nextInt();
        while (t-- > 0) {
            int n = sc.nextInt();
            int[] a = new int[n];
            for (int i = 0; i < n; i++) {
                a[i] = sc.nextInt();
            }
            System.out.println(minOperations(a, n));
        }
    }

    private static int minOperations(int[] a, int n) {
        boolean allZero = true;
        int c=0;
        for (int num : a) {
            if (num == 0) {
                c++;
            }
        }
        if(c==0) return 1;
        if(c==n)return 0;
        boolean check=false;
        for (int i = 1; i < a.length - 1; i++) {
            if (a[i] == 0 && a[i - 1] != 0 && a[i + 1] != 0) {
                check=true;
            }
        }
        if(check)return 2;
        else return 1;

    }
}

**Instructions:**
- Focus on edge cases or scenarios that maximize the failure probability in faulty solutions.
- Due to the output length limit, you should generate a **small-scale** test input that is **complete and valid**.
- Output the test input directly, not code to generate it.

**Output format:**
```plaintext
{test input}
```

Think step by step.

Response:
```plaintext
3
5
1 0 2 0 3
5
1 2 3 4 5
5
0 1 0 1 0
```


**Task:**
Generate a challenging test input that exposes the bug in the buggy code of the algorithm problem:
Algorithm Problem:
Title: MEX Destruction
time_limit_ms: 1000
memory_limit_mb: 256
Description: Evirir the dragon snuck into a wizard's castle and found a mysterious contraption, and their playful instincts caused them to play with (destroy) it...

Evirir the dragon found an array $$$a_1, a_2, \ldots, a_n$$$ of $$$n$$$ non-negative integers.

In one operation, they can choose a non-empty subarray$$$^{\text{∗}}$$$ $$$b$$$ of $$$a$$$ and replace it with the integer $$$\operatorname{mex}(b)$$$$$$^{\text{†}}$$$. They want to use this operation any number of times to make $$$a$$$ only contain zeros. It can be proven that this is always possible under the problem constraints.

What is the minimum number of operations needed?

Input: Each test contains multiple test cases. The first line contains the number of test cases $$$t$$$ ($$$1 \le t \le 200$$$). The description of the test cases follows.

The first line of each test case contains a single integer $$$n$$$ ($$$1 \le n \le 50$$$), the length of $$$a$$$.

The second line of each test case contains $$$n$$$ space-separated integers, $$$a_1, a_2, \ldots, a_n$$$ ($$$0 \le a_i \le 100$$$).

It is guaranteed that the sum of $$$n$$$ over all test cases does not exceed $$$500$$$.

Output: For each test case, output a single integer on a line, the minimum number of operations needed to make $$$a$$$ contain only zeros.

Examples:
input:
10
4
0 1 2 3
6
0 0 0 0 0 0
5
1 0 1 0 1
5
3 1 4 1 5
4
3 2 1 0
7
9 100 0 89 12 2 3
4
0 3 9 0
7
0 7 0 2 0 7 0
1
0
2
0 1
output:
1
0
2
1
1
2
1
2
0
1

Note: In the first test case, Evirir can choose the subarray $$$b = [1, 2, 3]$$$ and replace it with $$$\operatorname{mex}(1, 2, 3) = 0$$$, changing $$$a$$$ from $$$[0, \underline{1, 2, 3}]$$$ to $$$[0, 0]$$$ (where the chosen subarray is underlined). Therefore, the answer is $$$1$$$.

In the second test case, $$$a$$$ already contains only $$$0$$$s, so no operation is needed.

In the third test case, Evirir can change $$$a$$$ as follows: $$$[1, \underline{0, 1, 0, 1}] \to [\underline{1, 2}] \to [0]$$$. Here, $$$\operatorname{mex}(0, 1, 0, 1) = 2$$$ and $$$\operatorname{mex}(1, 2) = 0$$$.

In the fourth test case, Evirir can choose $$$b$$$ to be the entire array $$$a$$$, changing $$$a$$$ from $$$[\underline{3, 1, 4, 1, 5}]$$$ to $$$[0]$$$.

Buggy Code:
import java.util.*;
public class MEX {
    public static void main(String[] args)
    {
        Scanner in=new Scanner(System.in);
        int t=in.nextInt();
        for(int z=1;z<=t;z++)
        {
        int n=in.nextInt();
        int[] a=new int[n];
        int c=0;int c1=0;int k=0;boolean flag=true;int x=0;
        for(int i=0;i<n;i++)
        {
            a[i]=in.nextInt();
            if(a[i]!=0)
            {
                x++;
            }
            if(a[i]==0 && i!=0 && i!=n-1)
            {
                c++;
                flag=false;
            }
            else if(flag==true && a[i]!=0 && i!=0 && i!=n-1)
            {
                k++;
            }
            if(a[i]==0)
            c1++;
        }
        if(c1==n)
        {
            System.out.println("0");
        }
        else if(x==1 && c1==n-1)
        {
            System.out.println("1");
        }
        else
        {
            if(c1-c==2||c1-c==0)
            {
                if(c>0)
                {
                    System.out.println("2");
                }
                else
                {
                    System.out.println("1");
                }
            }
            else
            {
                if(c>0 && (k+c)==n-2)
                {
                    System.out.println("1");
                }
                else if(c>0)
                {
                    System.out.println("2");
                }
                else
                {
                    System.out.println("1");
                }
            }
}
    }
}
}

**Instructions:**
- Focus on edge cases or scenarios that maximize the failure probability in faulty solutions.
- Due to the output length limit, you should generate a **small-scale** test input that is **complete and valid**.
- Output the test input directly, not code to generate it.

**Output format:**
```plaintext
{test input}
```

Think step by step.

Response:
```plaintext
5
5
0 1 2 0 3
4
1 0 0 2
6
0 1 2 3 4 5
3
0 1 0
2
1 1
```