<p>I have multiple _test.go files. And I would like to know if I can run them in order.</p>
<hr/>**评论：**<br/><br/>TheMerovius: <pre><p>Not really. From <a href="https://golang.org/ref/spec#Package_initialization" rel="nofollow">the spec</a></p>
<blockquote>
<p>The declaration order of variables declared in multiple files is determined by
the order in which the files are presented to the compiler: Variables declared
in the first file are declared before any of the variables declared in the
second file, and so on.</p>
</blockquote>
<p>In general, you should consider the order in which files are presented to the compiler to be unspecified. There are, theoretically, ways to do that, but you really shouldn't, because you will rely on users or developers of your package to do special tricks, instead of just having a regular old <code>go test</code> work as expected.</p>
<p>Might I ask what problem you are trying to solve? In general, you should try as hard as you can to isolate your test-cases from each other and in that case it shouldn't matter which order they are executed in.</p></pre>Keefle: <pre><p>I'm trying to break down a big test file into multiple organised test files.. but some tests depend on others. And some must be tested before others</p></pre>TheMerovius: <pre><p>But why? Like, why would the tests not be isolated? It's bad form for one test to depend on state from another test. You are likely fitting square peg of a testing pattern from another language into the round hole of Go testing.</p>
<p>If failure of one test implies failure of another, it's fine to run both and have both fail - in fact, that gives far more information. If you need to check that a sequence of action gives the intended result, then put them in one test function; it is one test. I would even go so far as to argue that your tests should, as far as possible, start with a call to <code>t.Parallel</code>, so you don't even get into these bad habits in the first place…</p>
<p>In any case, you can use <a href="https://godoc.org/testing#hdr-Subtests_and_Sub_benchmarks" rel="nofollow">subtests</a> to induce an order on tests, if need be. I.e. don't export the test functions and call them manually via <code>t.Run</code> from a master-test. But, again, it's bad form.</p></pre>Keefle: <pre><p>Alrighty then.. I'll step away from these habits.. Gotta rethink the structure of the tests and rewrite them.. reuse what I can.. etc<br/>
Thanks for taking the time to answer :3
much appreciated</p></pre>NeedsMoreTests: <pre><blockquote>
<p>but some tests depend on others</p>
</blockquote>
<p>That's generally considered a poor design to be honest (regardless of language). That means you can't run individual tests by themselves which means you must run the whole test suite or build that knowledge into the testing framework which means you can introduce bugs. This also makes it harder to write new tests.</p>
<p>I don't know what you're working on but I'd highly suggest creating structs or functions that encapsulate enough of the setup that you can run a test by itself. Even if it makes the tests slower or requires some copy/pasting in a couple of cases it's better than having the inter-dependency IMHO.</p></pre>Keefle: <pre><p>hmm.. I see.. then I should rethink and restructure the whole tests and reuse what i can.. Thanks for taking the time to answer :3</p></pre>NeedsMoreTests: <pre><p>Yeah that's what I would do and thanks for taking the time to listen. I know it probably seems counter-intuitive but I've always considered writing tests to be fundamentally different than normal coding in that I try to forget what the internals do and write tests from the perspective of a user of my code. I also try and write test cases so they only test one thing that way when something breaks there's specific test cases to look at instead of wading through a test case with dozens of checks.</p>
<p>Here's some example code:</p>
<pre><code>package main
const DefaultValue = 42
type Config struct {
setup bool
Default int
}
func (c *Config) GetDefault() int {
if !c.setup {
panic("not setup")
}
if c.Default != 0 {
return c.Default
}
return DefaultValue
}
</code></pre>
<p>I'd write two test cases:</p>
<pre><code>func TestConfig_GetDefaultNotSet(t *testing.T) {
cfg := &Config{}
if cfg.GetDefault() != DefaultValue {
t.Fatal()
}
}
func TestConfig_GetDefault(t *testing.T) {
cfg := &Config{Default: 2}
if cfg.GetDefault() != 2 {
t.Fatal()
}
}
</code></pre>
<p>Note however the above will panic because I didn't set <code>*Config.setup</code> to <code>true</code> anywhere. From a user's perspective, that's exactly what would happen because <code>setup</code> is private and cannot be modified outside of my package. So, because I'm not testing from my own perspective I realize I need to write a function and call that instead in a test:</p>
<pre><code>func NewConfig() *Config {
return &Config{setup: true}
}
func TestConfig_GetDefaultNotSet(t *testing.T) {
cfg := NewConfig()
if cfg.GetDefault() != DefaultValue {
t.Fatal()
}
}
</code></pre>
<p>On a somewhat related note, gocheck is a really nice library that you might consider looking at: <a href="https://labix.org/gocheck" rel="nofollow">https://labix.org/gocheck</a>. I know there's probably several people here that would advise against it, and that's perfectly fine, but it does help to simplify the setup/teardown of tests and suites while also failures easier to read.</p></pre>hell_0n_wheel: <pre><blockquote>
<p>some tests depend on others</p>
</blockquote>
<p>If you need to establish some state before running a test, consider writing a fixture, and include a test whose sole purpose is to ensure the fixture is correct.</p>
<p>The simplest of fixtures can be built on <code>testing.Main</code>: <a href="https://golang.org/pkg/testing/#hdr-Main" rel="nofollow">https://golang.org/pkg/testing/#hdr-Main</a></p></pre>nstratos: <pre><p>If you really wish to do it, there is a way: <a href="https://golang.org/pkg/testing/#hdr-Main" rel="nofollow">https://golang.org/pkg/testing/#hdr-Main</a></p>
<p>But as others have pointed out you should try to write tests that can run in isolation.</p></pre>
