Lines Matching refs:code

11 in your own code.
151 `ConcretePacketStream` in production code and to use `MockPacketStream`
156 One way to do it is to templatize your code that needs to use a packet
157 stream.  More specifically, you will give your code a template type
175 `PacketReader<ConcretePacketStream>` in production code, and use
191 code to use an interface (abstract class).
213 Your code should talk to `FileInterface` to open a file.  Now it's
243   ... code that uses mock_foo ...
258   ... code that uses mock_foo ...
274   ... code that uses mock_foo ...
287   ... code that uses mock_foo ...
301 …code without changing its externally visible behavior, ideally you should't need to update any tes…
355 interfaces. In order to test your code that uses such a class (let's
372 to interfaces": instead of talking to the `Concrete` class, your code
375 mock that interface to observe how your code is doing.
385 …ff, etc instead of just trimming the class. This allows you to write your code (user of the interf…
386 …absorb the change in your implementation of the interface, and your other code and tests will be i…
389 will end up writing lots of redundant code. This concern is totally
393 …ll have its own domain-specific interface on top of `Concrete`, and they will not be the same code.
488 …his**. We would only recommend to do it as an intermediate step when you are refactoring your code.
493 operations. And suppose you want to test how your code uses `System`
508 that you can test the error handling code) or unintentional. If your
510 could end up with code that passes the tests but fails in production.
550 With this, Google Mock will verify that your code made the right calls
558 Ideally, you should code to interfaces, whose methods are all pure
709 The code won't compile if any of these conditions aren't met.
1250 … Not really. Every `EXPECT_CALL` adds a constraint on the behavior of the code under test. Having …
1254 The answer, lies in _what_ a test should verify. **A good test verifies the contract of the code.**…
1258 … `EXPECT_CALL`s in different `TEST_F`s to verify different aspects of the code's behavior. Compare…
1310 **An unexpected call is always an error,** as the code under test doesn't behave the way the test e…
1328   // Use mock_registry in code under test.
1551 Unfortunately, it doesn't work here. The above code will fail with error:
1783 `Clear()` calls are right next to the code that uses your mock.
2239 gMock in April 2017; in older code, you may find more complex
2243 snippets called “buzzes”. Your code uses these types:
2280 following code examples, we assume that we have defined a `MockBuzzer` object
2319 Note that `ByMove()` is essential here - if you drop it, the code won’t compile.
2372 2017. In older code, you may encounter the following workaround for the lack of
2476 Well, it might be created on the heap and owned by the code you are
2477 testing. Suppose there's a bug in that code and it doesn't delete the
2538 exercising code:
2637 code in a single-threaded context. That avoids race conditions and
2648   1. The code under test calls methods of `foo`.
2650 …1. Destroy the mock yourself, or let the code under test destroy it. The destructor will automatic…
2655 …* Execute your _test code_ (as opposed to the code being tested) in _one_ thread. This makes your …
2702 your tests or learning about the behavior of the code you are testing,
2729 of the `EXPECT_CALL`s? Or is the code under test doing something
3028 passing the parameters by pointer usually makes your code more
3279 family to quickly define a new action that can be used in your code as
3300 arguments.  Rest assured that your code is type-safe though: