> > So in summary, it sounds like we agree on the following guidelines: > > 1) If you're committing a CL and it is possible to test it through the SB > API, you should only submit an SB API test, and not a HandleCommand test.
agreed > 2) If you're committing a CL and it's not possible to test it through the SBI > API but it does make sense for the SB API, you should extend the SB API at > the same time as your CL, and then refer back to #1. agreed > 3) If it is not possible to test it through the SB API and it does not make > sense to add it to the SB API from a design perspective, you should consider > writing a unit test for it in C++. This applies especially for utility > classes and data structures. agreed > 4) Finally, if none of the above are true, you can write a HandleCommand test. agreed > > One more question: I mentioned earlier that we should enforce the distinction > between HandleCommand tests and python api tests at an organizational level. > In other words, all HandleCommand tests go in lldb/test/command-api, and all > new SB API tests go in lldb/test/command-api. Eventually the goal would be > to only have 3 toplevel directories under lldb/test. unittests, command-api, > and python-api. But this would take some time since it would be on a > move-as-you-touch basis, rather than all at once. Does this seem reasonable > as well? I really don't care for the "python-api" or "command-api" directories. We should make tests as needed without needing to place them into specific API or command line bins. I don't want two directories like: test/command-api/lang/c/.... test/public-api/lang/c/.... I would rather us just write the tests as needed and do what is right for the tests. The API/command directories add no value. I am fine with having these directories when say we are trying to compile against the public API as a test in itself, but we don't need to go moving or putting tests into these directories. Greg _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
