Test `start.lisp`

[aadcg]

The first battery of tests should be done in the context of nyxt since doing it on the level of nyxt/renderer raises the complexity bar.

For all start parameters check that:

• (nyxt:start :parameter t) => variable corresponding to parameter is rightly set
• Don't clean Nyxt's state
• (nyxt:start) => ensure that parameter fallbacks to the default value.

In the context of nyxt/renderer, there are some important checks:

• To test entry-point and start:
  • either add an option to pass a handler after init;
  • or have start reuse an existing *browser*;
  • or (best option in my opinion), have a client listen to the socket for readiness, then send instruction to quit.
• To test all other browser initialization features, bypass start and initialize browser ourselves.

[aadcg]

@Ambrevar notice that I have taken some of your words to formulate this issue. Please let me know if this plan makes sense as a whole.

[Ambrevar]

All good!

[aadcg]

This issue is a duplicate of #1199.

Quoting the original post from @Ambrevar below.

---

Our startup test suite is very limited for now. It's critical and it's broken many times in the past, and I expect it will break again.

We need to test the combination of the following.

• nosave data profile
• dev data profile
• init.lisp errors
• no socket
• custom socket
• multi instance
• remote execution
• remote URL query
• default package
• REPL startup
• binary startup

If I forgot something, please mention it! :)

[aartaka]

Are init errors actually caught properly? I was unable to see them for the last month, but it might be my config that borks it up...

[aadcg]

If you're referring to errors arising from the config file, I do get them.

[aartaka]

Okay, the issue is on my side then, thanks for confirming!

[aadcg]

Commit 69985ad811e597b9165e9e1e5f60f9c058190d27 introduces a rather odd idiom to the startup logic, since it creates a dummy buffer that is deleted.