/* ChibiOS/RT - Copyright (C) 2006-2007 Giovanni Di Sirio. This file is part of ChibiOS/RT. ChibiOS/RT is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. ChibiOS/RT is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . */ /** * @page article_design Designing an embedded application * ChibiOS/RT offers a variety of mechanisms and primitives, often it is * better to focus on a single approach for the system design and use only * part of the available subsystems.
* When designing your application you may choose among several design * alternatives: * - @ref nothreads * - @ref messpass * - @ref thdshared * - @ref thdmixed * . * @section nothreads Single threaded superloop * Correct, single thread, it is not mandatory to use the multithreading * features of the OS. You may choose to implements everything as a complex * state machine handled in the main thread alone. In this scenario the OS * still offers a variety of useful mechanisms: * - Interrupt handling. * - Virtual Timers, very useful in state machines in order to handle time * triggered state transitions. * - Power management. * - Event Flags and/or Semaphores as communication mechanism between * interrupt handlers and the main. * - I/O queues. * - Memory allocation. * - System time. * . * In this configuration the kernel size is really minimal, everything else * is disabled and takes no space. You always have the option to use more * threads at a later time in order to perform separate tasks. * * @section messpass Message Passing * In this scenario there are multiple threads in the system that never * share data, everything is done by exchanging messages. Each thread * represents a service, the other threads can request the service by sending * a message.
* In this scenario the following subsystems can be used: * - Synchronous Messages. * - Mailboxes (asynchronous message queues). * . * The advantage of this approach is to not have to deal with mutual exclusion, * each functionality is encapsulated into a server thread that sequentially * serves all the requests. As example, you can have the following scenario: * - A buffers allocator server. * - A disk driver server. * - A file system server. * - One or more client threads. * . * Example: *

* @dot digraph example { rankdir="RL"; node [shape=rectangle, fontname=Helvetica, fontsize=8, fixedsize="true", width="1.2", height="0.75"]; edge [fontname=Helvetica, fontsize=8]; disk [label="Server Thread\nDisk Driver"]; buf [label="Server Thread\nBuffers Allocator"]; fs [label="Client&Server Thread\nFile System"]; cl1 [label="Client Thread"]; cl2 [label="Client Thread"]; cl3 [label="Client Thread"]; fs -> disk [label="I/O request", constraint=false]; disk -> fs [label="status", style="dotted", constraint=false]; fs -> buf [label="buffer request"]; buf -> fs [label="buffer", style="dotted"]; cl1 -> fs [label="FS transaction"]; fs -> cl1 [label="result", style="dotted"]; cl2 -> fs [label="FS transaction"]; fs -> cl2 [label="result", style="dotted"]; cl3 -> fs [label="FS transaction"]; fs -> cl3 [label="result", style="dotted"]; } * @enddot *

* Note that the threads should not exchange complex messages but just * pointers to data structures in order to optimize the performance. * Also note that a thread can be both client and server at the same * time, the FS service in the previous scenario as example. * * @section thdshared Threads sharing data * This is the most common scenario, several threads have access to both their * private data and shared data. Synchronization happens with one of the * mechanisms described in the @ref article_mutual_exclusion article.
* * @section thdmixed Mixed * All the above approaches can be freely mixed in a single application but * usually I prefer to choose a way and consistently design the system around * it. The OS is a toolbox that offers a lot of tools but you don't have * to use them all necessarily. */ 3 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439
(**Note:** If you get compiler errors that you don't understand, be sure to consult [Google Mock Doctor](http://code.google.com/p/googlemock/wiki/V1_6_FrequentlyAskedQuestions#How_am_I_supposed_to_make_sense_of_these_horrible_template_error).)

# What Is Google C++ Mocking Framework? #
When you write a prototype or test, often it's not feasible or wise to rely on real objects entirely. A **mock object** implements the same interface as a real object (so it can be used as one), but lets you specify at run time how it will be used and what it should do (which methods will be called? in which order? how many times? with what arguments? what will they return? etc).

**Note:** It is easy to confuse the term _fake objects_ with mock objects. Fakes and mocks actually mean very different things in the Test-Driven Development (TDD) community:

  * **Fake** objects have working implementations, but usually take some shortcut (perhaps to make the operations less expensive), which makes them not suitable for production. An in-memory file system would be an example of a fake.
  * **Mocks** are objects pre-programmed with _expectations_, which form a specification of the calls they are expected to receive.

If all this seems too abstract for you, don't worry - the most important thing to remember is that a mock allows you to check the _interaction_ between itself and code that uses it. The difference between fakes and mocks will become much clearer once you start to use mocks.

**Google C++ Mocking Framework** (or **Google Mock** for short) is a library (sometimes we also call it a "framework" to make it sound cool) for creating mock classes and using them. It does to C++ what [jMock](http://www.jmock.org/) and [EasyMock](http://www.easymock.org/) do to Java.

Using Google Mock involves three basic steps:

  1. Use some simple macros to describe the interface you want to mock, and they will expand to the implementation of your mock class;
  1. Create some mock objects and specify its expectations and behavior using an intuitive syntax;
  1. Exercise code that uses the mock objects. Google Mock will catch any violation of the expectations as soon as it arises.

# Why Google Mock? #
While mock objects help you remove unnecessary dependencies in tests and make them fast and reliable, using mocks manually in C++ is _hard_:

  * Someone has to implement the mocks. The job is usually tedious and error-prone. No wonder people go great distance to avoid it.